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

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

[Kevin Buettner]

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.

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

[Kevin Buettner]

On Aug 4,  9:30am, Kevin Buettner wrote:

>      - Kevin, Sept 4, 2000 ]
                ^^^^
Okay, so I really seem to have a problem with the month of August.  (I
also sent a recent message claiming that August was also July.)  Anyway,
thanks to Elena for pointing this out to me.  It's fixed now.
From ezannoni@cygnus.com Fri Aug 04 10:28:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA]: Fix hash table bugs in minsyms.c
Date: Fri, 04 Aug 2000 10:28:00 -0000
Message-id: <14730.64814.976208.581246@kwikemart.cygnus.com>
References: <1000804003817.ZM3200@ocotillo.lan>
X-SW-Source: 2000-08/msg00098.html
Content-length: 5640

Kevin Buettner writes:
 > I request approval for committing the patch below.
 > 

Go ahead, it makes sense. 
Thanks
Elena 

 > 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.
 > 
From eliz@delorie.com Fri Aug 04 11:10:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Protoize ch-exp.c, core-regset.c
Date: Fri, 04 Aug 2000 11:10:00 -0000
Message-id: <200008041810.OAA28507@indy.delorie.com>
References: <1000803190941.ZM2697@ocotillo.lan> <200008040931.FAA28059@indy.delorie.com> <1000804151730.ZM4041@ocotillo.lan>
X-SW-Source: 2000-08/msg00099.html
Content-length: 564

> Date: Fri, 4 Aug 2000 08:17:30 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> Okay... here's what I'll do.  I'll make a reasonable stab at moving
> comments embedded in the parameter list to before the function along
> with some minimal prefatory remarks.  I ask that maintainers of the
> affected files (and anyone else who's interested) look over these
> changes to make sure that they aren't objectionable.

I don't think anyone could expect more.  I agree with this plan, and
will try to review all the patches you post for this as closely as I
can.

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

[Stan Shebs]

Kevin Buettner wrote:
> 
> I am working on a project which required me to add support for the
> DWARF version 2.1 64-bit format.

Cool!

> The DWARF 2 draft document that I based these changes on is at:

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!

Stan
From eager@eagercon.com Thu Aug 03 15:49:00 2000
From: Michael Eager <eager@eagercon.com>
To: Kevin Buettner <kevinb@cygnus.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 15:49:00 -0000
Message-id: <3989F6AC.70758991@eagercon.com>
References: <1000803222955.ZM2958@ocotillo.lan>
X-SW-Source: 2000-08/msg00077.html
Content-length: 1739

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.

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.  

I certainly welcome real life experience with the Dwarf 2 extensions. 
Where is there a need for Dwarf sections over 4Gb?

Kevin Buettner wrote:
> 
> I request approval for committing the patch below.
> 
> I am working on a project which required me to add support for the
> DWARF version 2.1 64-bit format.  In a nutshell, the 64-bit format
> makes certain offset and length fields 64 bits wide instead of merely
> 32 bits wide, thus making it possible to have DWARF2 sections that are
> larger than 4GB in size.  (Crazy, huh?)  In order to tell which type of
> format you have, the initial length field at the beginning of certain
> sections will either have a normal 32-bit length, or an escape value
> (0xffffffff) followed by a 64 bit length.  Once you've seen one of
> these 64 bit lengths, you know that certain other fields in the same
> section (section lengths and section offsets) will also be 64-bit
> values.  Note that the initial length field with either occupy 4 or 12
> bytes while the later length and offset fields will either occupy 4 or
> 8 bytes.
> 
> The DWARF 2 draft document that I based these changes on is at:
> 
>     http://reality.sgi.com/dehnert_engr/dwarf/dwarf2p1-draft4-000720.pdf
> 

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
From curtisv@lineo.com Thu Aug 03 15:54:00 2000
From: Curtis Veit <curtisv@lineo.com>
To: gdb-patches@sources.redhat.com
Subject: re:Trouble compiling gdb for host=i686 target=mips
Date: Thu, 03 Aug 2000 15:54:00 -0000
Message-id: <3989F835.4943B2B7@lineo.com>
X-SW-Source: 2000-08/msg00078.html
Content-length: 2222

I seem to have found the answer to my question concerning
BFD_RELOC_MIPS_HIGHER and BFD_RELOC_MIPS_HIGHEST.

The patches I found by Maciej W. Rozycki seem to be missing
definitions in bfd/bfd-in2.h and libbfd.h   I include a patch below.

This patch  *is*  needed in the snapshot for july 31 also.

There was also a problem when using the source to have
sim/mips/m16.igen dissappear  (I think after a make clean)
resulting in make giving a "don't know how to make target m16.igen"
or something similar.  I don't know what I should change to fix this.
(I just got another copy of m16.igen at the time.)

I have also changed to building with --target=mipsel-little-linux-gnu
for the present.

I hope this is helpful.

Regards,

Curtis
curtisv@lineo.com

> I am going to be doing a bit of work in the near future with gdb
(remote
> debug for
> various targets.  mips, ppc, sh, and arm) so I hope  in future I might

> actually do
> something helpful, for today though I'm afraid  that this is mainly a
> request for help.
> I've been trying to figure this out for a couple days now and find I
am
> lost!
>
> I seem to be having trouble compiling gdb-5.0 configured for
> --host=i686-pc-linux-gnu
> and
> --target=mipsel-elf-linux
>
> I am using stock gdb-5.0 with the mips patches by Maciej W. Rozycki
from
> the gdb-patches mailing list.
> (also available from  ' http://www.ds2.pg.gda.pl/~macro/gdb-5.0/ '.)


Here is the simple patch I needed:

diff -u --recursive gdb-5.0.macro/bfd/bfd-in2.h gdb-5.0/bfd/bfd-in2.h
--- gdb-5.0.macro/bfd/bfd-in2.h Wed Apr 19 00:32:31 2000
+++ gdb-5.0/bfd/bfd-in2.h       Thu Aug  3 11:03:13 2000
@@ -1971,6 +1971,8 @@
   BFD_RELOC_MIPS_GOT_PAGE,
   BFD_RELOC_MIPS_GOT_OFST,
   BFD_RELOC_MIPS_GOT_DISP,
+  BFD_RELOC_MIPS_HIGHER,
+  BFD_RELOC_MIPS_HIGHEST,


 /* i386/elf relocations */
diff -u --recursive gdb-5.0.macro/bfd/libbfd.h gdb-5.0/bfd/libbfd.h
--- gdb-5.0.macro/bfd/libbfd.h  Fri Apr  7 18:10:49 2000
+++ gdb-5.0/bfd/libbfd.h        Thu Aug  3 11:06:58 2000
@@ -705,6 +705,8 @@
   "BFD_RELOC_MIPS_GOT_PAGE",
   "BFD_RELOC_MIPS_GOT_OFST",
   "BFD_RELOC_MIPS_GOT_DISP",
+  "BFD_RELOC_MIPS_HIGHER",
+  "BFD_RELOC_MIPS_HIGHEST",

   "BFD_RELOC_386_GOT32",
   "BFD_RELOC_386_PLT32",