From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Kevin Buettner Cc: Elena Zannoni , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] DWARF v2.1 64-bit support Date: Thu, 03 Aug 2000 15:44:00 -0000 Message-id: <3989F5D1.4CE33870@apple.com> References: <1000803222955.ZM2958@ocotillo.lan> X-SW-Source: 2000-08/msg00076.html 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 To: Kevin Buettner Cc: Elena Zannoni , 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 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",