This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB.
- From: Peter Schauer <peterschauer at gmx dot net>
- To: ppluzhnikov at google dot com (Paul Pluzhnikov)
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 9 Dec 2008 12:29:52 +0100 (CET)
- Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB.
I had the same problem a very long time ago when trying to debug
32 bit stabs executables with a sparc Solaris 64 bit GDB.
I came up with the following local hack, but didn't dare to RFA it
back then, as it didn't look clean enough.
We abandoned sparc Solaris development later on and were no longer
interested in a proper fix.
*** ./stabsread.c.orig Sat Jul 20 11:51:50 2002
--- ./stabsread.c Sun Jul 28 10:43:45 2002
***************
*** 927,932 ****
--- 927,935 ----
case 'l':
SYMBOL_TYPE (sym) = read_type (&p, objfile);
SYMBOL_CLASS (sym) = LOC_LOCAL;
+ /* Sign extend value for 64x32 GDB. */
+ if ((sizeof (CORE_ADDR) > 4) && ((valu & ~0x7fffffff) == 0x80000000))
+ valu = (valu ^ 0x80000000) - 0x80000000;
SYMBOL_VALUE (sym) = valu;
SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
add_symbol_to_list (sym, &local_symbols);
***************
*** 947,952 ****
--- 950,958 ----
SYMBOL_TYPE (sym) = read_type (&p, objfile);
SYMBOL_CLASS (sym) = LOC_ARG;
+ /* Sign extend value for 64x32 GDB. */
+ if ((sizeof (CORE_ADDR) > 4) && ((valu & ~0x7fffffff) == 0x80000000))
+ valu = (valu ^ 0x80000000) - 0x80000000;
SYMBOL_VALUE (sym) = valu;
SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
add_symbol_to_list (sym, &local_symbols);
> On Mon, Dec 8, 2008 at 6:07 PM, Daniel Jacobowitz <drow@false.org> wrote:
>
> >> We end up with an impossible target address of 0x1ffffbf88.
> >
> > Conclusion doesn't follow from example
>
> Well, that's the value I observed in the debugger...
>
> > Do you mean that SYMBOL_VALUE is -16U or -16UL, and
> > that's where the wrapping comes from? But SYMBOL_VALUE is a long,
> > signed. Is SYMBOL_VALUE (long) 0xfffffff0?
>
> Yes:
>
> (top) p *var
> $1 = {ginfo = {name = 0x16feaa0 "ar_ptr", value = {ivalue =
> 4294967280, block = 0xfffffff0,
> bytes = 0xfffffff0 <Address 0xfffffff0 out of bounds>, address =
> 4294967280, chain = 0xfffffff0}, language_specific = {cplus_specific =
> {
> demangled_name = 0x0}}, language = language_c, section = 0,
> obj_section = 0x0}, type = 0x16fe418, symtab = 0x1702900,
> domain = VAR_DOMAIN, aclass = LOC_ARG, is_argument = 1, line = 2742,
> ops = 0x0, aux_value = 0x0, hash_next = 0x0}
>
> That value was set here:
>
> #0 define_symbol (valu=4294967280, string=0x2aaaabd3285c
> "ar_ptr:p(0,32)", desc=2742, type=160, objfile=0xed4070)
> at ../../src/gdb/stabsread.c:936
> #1 0x0000000000545f98 in process_one_symbol (type=160, desc=2742,
> valu=4294967280, name=0x2aaaabd3285c "ar_ptr:p(0,32)",
> section_offsets=0xe9bcf0, objfile=0xed4070) at ../../src/gdb/dbxread.c:3178
> #2 0x0000000000545001 in read_ofile_symtab (pst=0xf9cde8) at
> ../../src/gdb/dbxread.c:2600
> ...
>
> And that (AFAICT) is coming from BFD.
>
> So it appears that BFD gives us 0x00000000fffffff0, but GDB expects
> 0xfffffffffffffff0
>
> > If that's the case then the debug reader might be to blame.
>
> This is coming from a rather old glibc-2.2.2, compiled with
> non-exstent :) old compiler:
>
> GNU CC version 2.96 20000731 (Red Hat Linux 7.1 2.96-79).
>
> Here is what 'objdump -g /lib/i686/libc.so.6' has to say:
>
> static mchunkptr chunk_alloc (arena *ar_ptr /* 0x00000000fffffff0 */,
> size_t nb /* 0x00000000ffffffec */)
> { /* 0x000000000007f2f0 */
> { /* 0x000000000007f2f0 */
> register mbinptr q /* 0x0000000000000002 */;
> register mchunkptr bck /* 0x0000000000000007 */;
> ...
>
> And here is 'objdump --stabs':
>
> 105431 FUN 0 2746 0007f2f0 317480 chunk_alloc:f(0,25)
> 105432 PSYM 0 2742 fffffff0 317500 ar_ptr:p(0,32)
> 105433 PSYM 0 2742 ffffffec 317515 nb:p(3,2)
>
>
> --
> Paul Pluzhnikov
>
--
Peter Schauer Peter.Schauer@mytum.de