Loading ...
Sorry, an error occurred while loading the content.

gcc on red hat 7.0 is better for programmers

Expand Messages
  • Dan Kegel
    OK, so the gcc on Red Hat 7.0 can t be used to compile the kernel ( you have to use what they call kgcc ). A lot of people have given Red Hat flak for this
    Message 1 of 1 , Feb 13, 2001
      OK, so the gcc on Red Hat 7.0 can't be used to compile the kernel
      ( you have to use what they call kgcc ). A lot of people have
      given Red Hat flak for this and the C++ dynamic linking portability issue.

      But I just noticed a real nice thing about the gcc on red hat 7.0:
      it does better at stack tracebacks when a signal is received.

      I often use the code fragments listed at the bottom of this email to force
      a stack dump after a crash (not that I have many of them :-). Under older gcc's,
      it worked, but the stack was slightly screwed up, and it didn't
      show the crash point reliably. For instance, here's a stack dump
      from a program that calls crash_me() from main (where crash_me has
      a null pointer reference) under Red Hat 6.2:

      #0 0x402488c9 in __wait4 () from /lib/libc.so.6
      #1 0x402a71cc in ?? () from /lib/libc.so.6
      #2 0x401f7ccc in __libc_system (line=0xbfffee8c "gdb -batch -x gdbcmd ./mtserv 28026") at ../sysdeps/posix/system.c:136
      #3 0x400578ac in system (line=0xbfffee8c "gdb -batch -x gdbcmd ./mtserv 28026") at wrapsyscall.c:120
      #4 0x804f87d in dump_stack (signum=11) at mtserv.cc:54
      #5 0x401d5c48 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
      #6 0x805043b in main (argc=3, argv=0xbffff8d4) at mtserv.cc:291

      And here's the output under Red Hat 7.0:

      #0 0x40260e69 in __wait4 () from /lib/libc.so.6
      #1 0x402cce4c in __DTOR_END__ () from /lib/libc.so.6
      #2 0x401f69d2 in __libc_system (line=0xbfffe95c "gdb -batch -x gdbcmd ./mtserv 16394") at ../sysdeps/posix/system.c:136
      #3 0x4005b229 in system (line=0xbfffe95c "gdb -batch -x gdbcmd ./mtserv 16394") at wrapsyscall.c:159
      #4 0x804f0e6 in dump_stack (signum=11) at mtserv.cc:54
      #5 0x4005907e in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, ... oldmask = 2147483648, cr2 = 0}) at signals.c:97
      #6 <signal handler called>
      #7 0x804f104 in crash_me () at mtserv.cc:63
      #8 0x804fc4e in main (argc=3, argv=0xbffff464) at mtserv.cc:291
      #9 0x401c4f31 in __libc_start_main (main=0x804f954 <main>, argc=3, ubp_av=0xbffff464, init=0x804c588 <_init>, fini=0x809f9d8 <_fini>, rtld_fini=0x4000e274
      <_dl_fini>, stack_end=0xbffff45c) at ../sysdeps/generic/libc-start.c:129

      The output under Red Hat 7.0 with the new gcc is far more informative;
      it correctly identifies the exact line of the crash.

      - Dan

      static const char *argv0 = NULL;

      main(int argc, char **argv)
      argv0 = argv[0];
      signal(SIGSEGV, dump_stack);
      signal(SIGBUS, dump_stack);

      void dump_stack(int signum)
      (void) signum;
      char s[160];
      // Guess that there are three threads active... should probably dump more.
      system("echo 'info threads\nbt\nthread 3\nbt\nthread 4\nbt\nthread 5\nbt\n' > gdbcmd");

      sprintf(s, "gdb -batch -x gdbcmd %s %d", argv0, getpid());
      printf("Crashed! Starting debugger to get stack dump. You may need to kill -9 this process afterwards.\n");
    Your message has been successfully submitted and would be delivered to recipients shortly.