Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB.

[Peter Schauer <peterschauer@gmx.net>]

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