Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* GDB and 64 bit
@ 2002-01-15 11:11 ccroswhite
  2002-01-15 12:23 ` Kevin Buettner
  0 siblings, 1 reply; 5+ messages in thread
From: ccroswhite @ 2002-01-15 11:11 UTC (permalink / raw)
  To: gdb

Hello,

I am trying to get gdb to understand 64 bit applications.  I can not
compile gdb with a configuration option (that is configure
--host=sparcv9-sun-solaris2.8).  So I have gone in and replaced gcc with
gcc -m64 and ld with ld -64 (Solaris ld).   gdb will now open the
executable, however, it will not break and I have seen it print out
variables in both 64 bit and 32 bit.  I am not exactly sure why it is
doing both 1:) printing out 64 and 32 bit code and 2:) why it will not
break.


Any help would be greatly appreciated.

Chris Croswhite
Get2Chip, Inc.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GDB and 64 bit
  2002-01-15 11:11 GDB and 64 bit ccroswhite
@ 2002-01-15 12:23 ` Kevin Buettner
  2002-01-15 12:39   ` ccroswhite
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Buettner @ 2002-01-15 12:23 UTC (permalink / raw)
  To: ccroswhite, gdb

On Jan 15, 11:11am, ccroswhite@get2chip.com wrote:

> I am trying to get gdb to understand 64 bit applications.  I can not
> compile gdb with a configuration option (that is configure
> --host=sparcv9-sun-solaris2.8).  So I have gone in and replaced gcc with
> gcc -m64 and ld with ld -64 (Solaris ld).   gdb will now open the
> executable, however, it will not break and I have seen it print out
> variables in both 64 bit and 32 bit.  I am not exactly sure why it is
> doing both 1:) printing out 64 and 32 bit code and 2:) why it will not
> break.

Are the applications that you're debugging 32-bit or 64-bit?

Could you provide more detail (i.e, a cut and paste of a sample GDB
session) showing problems 1 and 2 above?

Thanks,

Kevin


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GDB and 64 bit
  2002-01-15 12:23 ` Kevin Buettner
@ 2002-01-15 12:39   ` ccroswhite
  2002-01-15 13:33     ` Kevin Buettner
  0 siblings, 1 reply; 5+ messages in thread
From: ccroswhite @ 2002-01-15 12:39 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: gdb

Kevin,

Here is an instance of both 1 and 2:

> gdb bin-sunos5/meta-g
GNU gdb 5.1
Copyright 2001 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 "sparc-sun-solaris2.8"...
(gdb) run
Starting program: /home/csun/code2/src/bin-sunos5/meta-g
This is the first line
This is the second line
This is the third line
Initializing Tcl shit
mm.c:900: failed assertion `((((void **) ptr) - headers_data_space(header)) %
num_words) == 0'

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
#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
(gdb) quit
The program is running.  Exit anyway? (y or n) y
> file bin-sunos5/meta-g
bin-sunos5/meta-g: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
> file /usr/local/bin/gdb
/usr/local/bin/gdb: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped


I have also included the executables and verified that it was linking in
everything that is 64 bit.

Chris Croswhite
Get2Chip, Inc.

Kevin Buettner wrote:

> On Jan 15, 11:11am, ccroswhite@get2chip.com wrote:
>
> > I am trying to get gdb to understand 64 bit applications.  I can not
> > compile gdb with a configuration option (that is configure
> > --host=sparcv9-sun-solaris2.8).  So I have gone in and replaced gcc with
> > gcc -m64 and ld with ld -64 (Solaris ld).   gdb will now open the
> > executable, however, it will not break and I have seen it print out
> > variables in both 64 bit and 32 bit.  I am not exactly sure why it is
> > doing both 1:) printing out 64 and 32 bit code and 2:) why it will not
> > break.
>
> Are the applications that you're debugging 32-bit or 64-bit?
>
> Could you provide more detail (i.e, a cut and paste of a sample GDB
> session) showing problems 1 and 2 above?
>
> Thanks,
>
> Kevin


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GDB and 64 bit
  2002-01-15 12:39   ` ccroswhite
@ 2002-01-15 13:33     ` Kevin Buettner
  2002-01-15 13:41       ` ccroswhite
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Buettner @ 2002-01-15 13:33 UTC (permalink / raw)
  To: ccroswhite, Kevin Buettner; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GDB and 64 bit
  2002-01-15 13:33     ` Kevin Buettner
@ 2002-01-15 13:41       ` ccroswhite
  0 siblings, 0 replies; 5+ messages in thread
From: ccroswhite @ 2002-01-15 13:41 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: gdb

Kevin,

Here is an attempt to set break point at begining of gdb run:

> gdb meta-g
GNU gdb 5.1
Copyright 2001 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 "sparc-sun-solaris2.8"...
(gdb) break main.c:1
Breakpoint 1 at 0xe0e20: file main.c, line 1.
(gdb) run
Starting program: /home/csun/code2/src/bin-sunos5/meta-g
warning: Cannot insert breakpoint 1:
Cannot access memory at address 0xe0e20
(gdb)

As you can see, I can not set it even at startup.

let me know if you need more info.

Chris Croswhite
Get2Chip, Inc.

Kevin Buettner wrote:

> 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-01-15 21:41 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-15 11:11 GDB and 64 bit ccroswhite
2002-01-15 12:23 ` Kevin Buettner
2002-01-15 12:39   ` ccroswhite
2002-01-15 13:33     ` Kevin Buettner
2002-01-15 13:41       ` ccroswhite

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox