On Fri, Jan 05, 2007 at 04:29:07PM +0200, Sami Liedes wrote:
> Yeah, I can run some debug versions for you if you wish. Just send me
> a patch for GDB or something. Though it might take some time as I'll
> have to take this computer to be repaired in the near future, but I'll
> try it after I get it back then.
>
> I thought you might find a backtrace from GDB useful. The line numbers
> are still from GDB version 6.5.dfsg-2. Also attached below are the
> contents of some structures I thought might be interesting.
Heck, if you're willing to build and debug GDB, we can do this
pretty quickly.
> #1 0x000000000054cb4f in find_location_expression (baton=0x457a968,
> locexpr_length=0x7fffdf0cd810, pc=47117658683169)
> at /home/sliedes/rec/gdb-6.5.dfsg/gdb/dwarf2loc.c:76
> low = 34084
> high = 47117658706294
> loc_ptr = (gdb_byte *) 0x2b54cc87aff7 ")\205"
> buf_end = (gdb_byte *) 0x2b54cc87aff7 ")\205"
> length = 8
> addr_size = 8
> base_mask = 18446744073709551615
> base_offset = 47117658386432
> base_address = 47117658672400
Well then, if loc_ptr == buf_end no wonder we're upset. But there's
more odd here...
> $1 = {base_address = 285968, data = 0x2b54cc87a550 "Æ\025", size = 2727,
> objfile = 0x13a8330}
baton->size is set to the end of the buffer to avoid overflow. 2727
bytes till the end implies that we're most of the way through the
section. But in fact the location list for this object should only be
30% of the way through this very large section:
<2><4d0d8>: Abbrev Number: 50 (DW_TAG_variable)
DW_AT_name : (indirect string, offset: 0xa937): currentVersion
DW_AT_decl_file : 1
DW_AT_decl_line : 2055
DW_AT_type : <48a5d>
DW_AT_location : 0x64530 (location list)
^^^^^^^ there.
> (gdb) print *baton->[EMAIL PROTECTED]
> $4 =
> "Æ\025\000\000\000\000\000\000d\026\000\000\000\000\000\000\003\000\221à{d\026\000\000\000\000\000\000t\026\000\000\000\000\000\000\001\000QP\027\000\000\000\000\000\000h\027\000\000\000\000\000\000\001\000Q±\027\000\000\000\000\000\000ß\027\000\000\000\000\000\000\001\000Qß\027\000\000\000\000\000\000\030\030\000\000\000\000\000\000\001\000Vu\030"
That's the data from the right place in the section. So maybe just the
size is wrong. And indeed, this location list is supposed to go from
0x64530 to 0x65771, which is 4673 bytes.
Oh lord.
(gdb) p dwarf2_per_objfile->loc_size - 410928
$18 = 854695
(gdb) p $ & 0xffff
$21 = 2727
"640K will be enough for everyone"
Does the attached patch make it happier?
--
Daniel Jacobowitz
CodeSourcery
Index: dwarf2loc.h
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2loc.h,v
retrieving revision 1.6
diff -u -p -r1.6 dwarf2loc.h
--- dwarf2loc.h 17 Dec 2005 22:33:59 -0000 1.6
+++ dwarf2loc.h 5 Jan 2007 15:31:17 -0000
@@ -39,7 +39,7 @@ struct dwarf2_locexpr_baton
gdb_byte *data;
/* Length of the location expression. */
- unsigned short size;
+ unsigned long size;
/* The objfile containing the symbol whose location we're computing. */
struct objfile *objfile;
@@ -55,7 +55,7 @@ struct dwarf2_loclist_baton
gdb_byte *data;
/* Length of the location list. */
- unsigned short size;
+ unsigned long size;
/* The objfile containing the symbol whose location we're computing. */
/* Used (only???) by thread local variables. The objfile in which
