Re: GDB problems

[Chris Plummer <darwin.plummer@sun.com>]

Theimo noticed that "gdb ls" produced the same problems I described
below with my app and suggested I contact gdb@sources.redhat.com. This
was the answer I got:

  This is a bug in the glibc headers used to build GDB.  It should be
  fixed in glibc CVS and in Debian unstable.

  If you want, you can fix your headers and rebuild gdb.  If I remember
  correctly you need to change two lines in sys/procfs.h to say:
  typedef elf_gregset_t prgregset_t;
  typedef elf_fpregset_t prfpregset_t;

I don't plan on taking this on at this time since I was able to resolve
the problem by compiling my app with -static. If anyone else gives
rebuilding gdb a try and has success, then let me know.

Thanks,

Chris

Chris Plummer wrote:
> 
> Sorry about all the emails. A couple of these issues are ones that I've
> had on my Qube 2 for a while and I was hoping would disappear on my
> Indy, but no such luck.
> 
> I'm having problems using GDB on an application of mine. I get a SIGTRAP
> before main() is even entered, and the pc is bad. The output of a gdb
> session is below. Also, if I attach to the already running app, I have
> similar problems with SIGTRAP. The only thing that seems to work is
> debugging a core, and even that doesn't always work (sometimes it thinks
> the pc is 0)
> 
> My program is somewhat big, but if you saw my previous email, you saw
> that there was no problem debugging even larger apps like xemacs and emacs.
> 
> BTW, this happens on both the Indy and Qube 2. Any help would be greatly
> appreciated. This problem is a really big priority for me, because if I
> can't debug this app with gdb, I'm hosed! :)
> 
> Thanks,
> 
> Chris Plummer
> 
> indy-01$ gdb testapp
> GNU gdb 2002-04-01-cvs
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "mips-linux"...
> (gdb) br main
> Breakpoint 1 at 0x606f0c: file main.c, line 18.
> (gdb) run
> Starting program: /usr/bin/testapp
> [New Thread 1024 (LWP 18281)]
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 1024 (LWP 18281)]
> warning: Warning: GDB can't find the start of the function at 0xffffffff.
> 
>     GDB is unable to find the start of the function at 0xffffffff
> and thus can't determine the size of that function's stack frame.
> This means that GDB may be unable to access that stack frame, or
> the frames below it.
>     This problem is most likely caused by an invalid program counter or
> stack pointer.
>     However, if you think GDB should simply search farther back
> from 0xffffffff for code which looks like the beginning of a
> function, you can increase the range of the search using the `set
> heuristic-fence-post' command.
> 0xffffffff in ?? ()
> (gdb) bt
> #0  0xffffffff in ?? ()
> #1  0x2aab73c8 in _dl_init () from /lib/ld.so.1
> Cannot access memory at address 0x38
> (gdb) p $pc
> $1 = -1
> (gdb)