Re: GDB and 64 bit

[Kevin Buettner <kevinb at redhat dot com>]

On Jan 15, 12:39pm, ccroswhite@get2chip.com wrote:

> Here is an instance of both 1 and 2:

Thanks.

> > gdb bin-sunos5/meta-g
[...]
> Program received signal SIGABRT, Aborted.
> 0xffffffff7e6a3074 in _libc_kill () from /usr/lib/64/libc.so.1
> (gdb) where
> #0  0xffffffff7e6a3074 in _libc_kill () from /usr/lib/64/libc.so.1
> #1  0xffffffff7e63cd44 in abort () from /usr/lib/64/libc.so.1

I agree that it does appear that GDB is confused about whether it's
debugging 32- or 64-bit code.  BTW, the sign extension problem looks
familiar.  See

    http://sources.redhat.com/ml/gdb/2001-10/msg00036.html

> #2  0x100ae3ab4 in Letext ()
> #3  0x100a0dbec in fre ()
> #4  0x100a12ab0 in free ()
> #5  0x1009f0764 in Tcl_Main ()
> #6  0x1000e2244 in main ()
> (gdb) break main.c:1
> Breakpoint 1 at 0xe0e20: file main.c, line 1.
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /home/csun/code2/src/bin-sunos5/meta-g
> warning: Cannot insert breakpoint 1:
> Cannot access memory at address 0xe0e20

Are you able to successfully run to a breakpoint in main() if you set
the breakpoint on the very first run of the program?  Sometimes GDB
has difficulties setting breakpoints when rerunning the program.  (This
should be fixed, but I'm trying to determine whether or not you can't
run to _any_ breakpoint or if it's just a problem with rerunning the
program...)

Thanks again,

Kevin