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

[Stan Shebs <shebs@apple.com>]

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",