Re: [PATCH RFA] DWARF v2.1 64-bit support

[Kevin Buettner <kevinb@cygnus.com>]

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 <kevinb@cygnus.com>
To: Stan Shebs <shebs@apple.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, 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> <shebs@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 <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, 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 <kevinb@cygnus.com>
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.