From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Michael Eager Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] DWARF v2.1 64-bit support Date: Thu, 03 Aug 2000 16:11:00 -0000 Message-id: <1000803231111.ZM3054@ocotillo.lan> References: <1000803222955.ZM2958@ocotillo.lan> <3989F6AC.70758991@eagercon.com> X-SW-Source: 2000-08/msg00079.html On Aug 3, 3:48pm, Michael Eager wrote: > One small disclaimer: Dwarf 2.1 is currently in draft status. Changes > from Dwarf 2.0 are not complete and the specification hasn't had either > final committee review, nor public review. It is subject to change. Understood. Thanks for the warning. > I don't anticipate that there will be changes to the 64-bit extension. > It is possible that the version numbering for Dwarf files may change, > perhaps if certain of the extensions are used. The code I've written doesn't rely on version numbers to do the right thing. Instead, it merely tests for the presence of the "escape" value in the initial length field of certain sections. It is my understanding that it's possible to have both 64-bit and 32-bit sections in the same file. The code I've written should handle this case, though I have not tested it. > I certainly welcome real life experience with the Dwarf 2 extensions. > Where is there a need for Dwarf sections over 4Gb? I haven't personally seen the need, but the vendor supplied tools generate 64-bit DWARF2.1 sections even though they're not really needed by any executables that I've seen. (I too would like to know where there's a need for sections larger than 4GB.) >From kevinb@cygnus.com Thu Aug 03 16:25:00 2000 From: Kevin Buettner To: Stan Shebs Cc: Elena Zannoni , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] DWARF v2.1 64-bit support Date: Thu, 03 Aug 2000 16:25:00 -0000 Message-id: <1000803232531.ZM3085@ocotillo.lan> References: <1000803222955.ZM2958@ocotillo.lan> <3989F5D1.4CE33870@apple.com> X-SW-Source: 2000-08/msg00080.html Content-length: 458 On Aug 3, 3:44pm, Stan Shebs wrote: > Just one nit: just in case the 2.1 drafting effort stalls or > disintegrates, add a comment in the code somewhere that this > change is based on a draft spec, and date it. As I know a > number of people have experienced, code that is based on an > unofficial and/or unavailable specification gets real mysterious > a couple years later! Assuming that the patch is approved, I will do as you suggest. Thanks! Kevin >From ac131313@cygnus.com Thu Aug 03 16:42:00 2000 From: Andrew Cagney To: David Taylor Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: [BUG] print_address_numeric Date: Thu, 03 Aug 2000 16:42:00 -0000 Message-id: <398A031E.C2DA4183@cygnus.com> References: <200008031747.NAA06630@texas.cygnus.com> X-SW-Source: 2000-08/msg00081.html Content-length: 1593 David Taylor wrote: > Right. And if TARGET_PTR_BIT was 16 bits instead of 32, then the > calculated length should be 2 bytes rather than 4 and it shouldn't > need to be special cased... at least, that is the theory. :-) > Hmmm, looking at them again, I think you're right; but I think that > the variable 'addr' is playing a dual role -- it's both an address and > a pointer. > it's an address. So, a POINTER_TO_ADDRESS probably needs to be thrown > in there. Yes. Probably wait until the problem has been proven. > TARGET_ADDR_BIT - it needs to (post) initializing it with somthing from > the architecture vector. I've never tried it ... > > Making the change and regenerating gdbarch.[ch], the function > verify_gdbarch now has the lines: > > if ((GDB_MULTI_ARCH >= 1) > && (gdbarch->ptr_bit == 0)) > internal_error ("gdbarch: verify_gdbarch: ptr_bit invalid"); > if (gdbarch->addr_bit == 0) > gdbarch->addr_bit = gdbarch->ptr_bit; > > + v:1:TARGET_ADDR_BIT:int:addr_bit::::8 * sizeof (void*):0:gdbarch->ptr_bit Check gdbarch.h for the non- multi-arch case. I suspect ``gdbarch->ptr_bit'' will need to be TARGET_PTR_BIT which is why I'm not 100% sure on it working. The hack: /* NOTE/WARNING: The parameter is called ``current_gdbarch'' so that it just happens to match the global variable ``current_gdbarch''. That way macros refering to that variable get the local and not the global version - ulgh. Once everything is parameterised with gdbarch, this will go away. */ I used on gdbarch_dump() may need to be re-used. Andrew >From kevinb@cygnus.com Thu Aug 03 17:38:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFA]: Fix hash table bugs in minsyms.c Date: Thu, 03 Aug 2000 17:38:00 -0000 Message-id: <1000804003817.ZM3200@ocotillo.lan> X-SW-Source: 2000-08/msg00082.html Content-length: 5175 I request approval for committing the patch below. I'm working on a project in which the OS wants to place certain groups of sections at different addresses than specified by the symbolic information in the executable. Thus it is necessary to call objfile_relocate() (in objfiles.c). objfile_relocate() calls msymbols_sort() which cause the minimal symbols to get sorted. The problem with this is that after the sort operation, the minimal symbol hash table entries are no longer correct. In fact, they are wildly incorrect. The reason for this is that the sort routine does not account for the motion of the symbol table entries in the hash table. In the process of diagnosing this problem, I took a close look at how the hash table was being constructed. The minimal symbols reside in an obstack and the hash table links are constructed in compact_minimal_symbols(). This code, as written, contains a minor bug, a fence post error in which the last symbol in the obstack was *not* added to the hash table. But it contains a much more serious bug as well. Because the symbols reside in an obstack, the obstack machinery is free to relocate the space up until the time obstack_finish() is called. Since the call to compact_minimal_symbols() (and hence the hash table creation) occurs before obstack_finish(), it is not safe to create references to the obstack entries since the space could get moved and any reference created could wind up being either incorrect or even dangling. In order to correct these problems, I've added a new function called build_minimal_symbol_hash_tables() which is called after obstack_finish() as well as after the sorting has been done in msymbols_sort. I've tested this patch on GNU/linux/x86 with the compiler set to generate DWARF2 info instead of the default (stabs). I've seen no regressions. (And better still, it also fixes the problems that I ran into on my project.) * minsyms.c (build_minimal_symbol_hash_tables): New function. (compact_minimal_symbols): Don't construct hash tables here. (install_minimal_symbols): Instead, construct them here. (msymbols_sort): And rebuild them here too. Index: minsyms.c =================================================================== RCS file: /cvs/src/src/gdb/minsyms.c,v retrieving revision 1.10 diff -u -p -r1.10 minsyms.c --- minsyms.c 2000/07/30 01:48:26 1.10 +++ minsyms.c 2000/08/03 23:27:59 @@ -801,11 +801,7 @@ compact_minimal_symbols (struct minimal_ copyfrom++; } else - { - *copyto++ = *copyfrom++; - - add_minsym_to_hash_table (copyto - 1, objfile->msymbol_hash); - } + *copyto++ = *copyfrom++; } *copyto++ = *copyfrom++; mcount = copyto - msymbol; @@ -813,6 +809,38 @@ compact_minimal_symbols (struct minimal_ return (mcount); } +/* Build (or rebuild) the minimal symbol hash tables. This is necessary + after compacting or sorting the table since the entries move around + thus causing the internal minimal_symbol pointers to become jumbled. */ + +static void +build_minimal_symbol_hash_tables (struct objfile *objfile) +{ + int i; + struct minimal_symbol *msym; + + /* Clear the hash tables. */ + for (i = 0; i < MINIMAL_SYMBOL_HASH_SIZE; i++) + { + objfile->msymbol_hash[i] = 0; + objfile->msymbol_demangled_hash[i] = 0; + } + + /* Now, (re)insert the actual entries. */ + for (i = objfile->minimal_symbol_count, msym = objfile->msymbols; + i > 0; + i--, msym++) + { + msym->hash_next = 0; + add_minsym_to_hash_table (msym, objfile->msymbol_hash); + + msym->demangled_hash_next = 0; + if (SYMBOL_DEMANGLED_NAME (msym) != NULL) + add_minsym_to_demangled_hash_table (msym, + objfile->msymbol_demangled_hash); + } +} + /* Add the minimal symbols in the existing bunches to the objfile's official minimal symbol table. In most cases there is no minimal symbol table yet for this objfile, and the existing bunches are used to create one. Once @@ -928,12 +956,13 @@ install_minimal_symbols (struct objfile ones and attempting to cache their C++ demangled names. */ for (; mcount-- > 0; msymbols++) - { - SYMBOL_INIT_DEMANGLED_NAME (msymbols, &objfile->symbol_obstack); - if (SYMBOL_DEMANGLED_NAME (msymbols) != NULL) - add_minsym_to_demangled_hash_table (msymbols, - objfile->msymbol_demangled_hash); - } + SYMBOL_INIT_DEMANGLED_NAME (msymbols, &objfile->symbol_obstack); + + /* Now build the hash tables; we can't do this incrementally + at an earlier point since we weren't finished with the obstack + yet. (And if the msymbol obstack gets moved, all the internal + pointers to other msymbols need to be adjusted.) */ + build_minimal_symbol_hash_tables (objfile); } } @@ -944,6 +973,7 @@ msymbols_sort (struct objfile *objfile) { qsort (objfile->msymbols, objfile->minimal_symbol_count, sizeof (struct minimal_symbol), compare_minimal_symbols); + build_minimal_symbol_hash_tables (objfile); } /* Check if PC is in a shared library trampoline code stub.