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

Paul Pluzhnikov
2008-12-09T01:33:32Z

Greetings,

This came up while debugging one of my core files.
The symptom is:

GNU gdb (GDB) 6.8.50.20081209-cvs
...
This GDB was configured as "x86_64-unknown-linux-gnu".
...
Core was generated by `/tmp/a.out'.
Program terminated with signal 11, Segmentation fault.
[New process 7763]
[New process 13974]
[New process 7773]
#0 chunk_alloc (ar_ptr=Cannot access memory at address 0xffffbf88 <<< What's that?
) at malloc.c:2896
2896 malloc.c: No such file or directory.
in malloc.c
(gdb) p ar_ptr
Cannot access memory at address 0xffffbf88

32-bit gdb doesn't have a problem on the same core:

Program terminated with signal 11, Segmentation fault.
[New process 7763]
[New process 13974]
[New process 7773]
#0 chunk_alloc (ar_ptr=0x1184f00, nb=10249) at malloc.c:2896

The problem is that in findvar.c:

case LOC_ARG:
if (frame == NULL)
return 0;
addr = get_frame_args_address (frame);
if (!addr)
return 0;
addr += SYMBOL_VALUE (var);
break;

What happens if sizeof(addr) == 8 (64-bit gdb), len == 4 (32-bit target),
get_frame_args_address() returns 0xffffbf98 (typical stack address)
and SYMBOL_VALUE() returns -16?

We end up with an impossible target address of 0x1ffffbf88.

Attached patch fixes this.
OK?

--
Paul Pluzhnikov

2008-12-08 Paul Pluzhnikov <ppluzhnikov@google.com>

* findvar.c (read_var_value): Truncate addr to target len.

Index: findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.119
diff -u -p -u -r1.119 findvar.c
--- findvar.c 2 Dec 2008 14:51:00 -0000 1.119
+++ findvar.c 9 Dec 2008 01:32:10 -0000
@@ -565,6 +565,10 @@ read_var_value (struct symbol *var, stru
break;
}

+ if (sizeof (addr) > len)
+ /* Truncate address to target length. */
+ addr &= (1L << (8 * len)) - 1;
+
VALUE_ADDRESS (v) = addr;
set_value_lazy (v, 1);
return v;