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

[ppluzhnikov@google.com (Paul Pluzhnikov)]

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;