On Tue, Mar 14, 2023 at 07:47:09AM +0000, Aditya Kamath1 wrote:
> This patch will enable vector register visibility when AIX FOLKS do core file analysis especially using applications like GDB.
Applied, with some formatting fixes.
--
Alan Modra
Australia Development Lab, IBM
[-- Attachment #1.1: Type: text/plain, Size: 6548 bytes --] Hi all, Please find attached the patch { 0001-Enable-vector-register-visibility-in-core-file-for-A.patch} This patch will enable vector register visibility when AIX FOLKS do core file analysis especially using applications like GDB. Kindly check the outputs with the patch and without the patch. Changes are visible in bold for the output with patch. Do let me know if any changes are required. If not kindly commit the same. Thanks and regards, Aditya. ------------------------- Output without patch:- ./gdb ~/gdb_tests/bll_core core.13828468 GNU gdb (GDB) 14.0.50.20230221-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc64-ibm-aix7.2.0.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/aditya/gdb_tests/bll_core... Core was generated by `bll_core'. #0 main () at /home/aditya/gdb_tests/bll_core.c:24 24 int length1 = 7; (gdb) info reg r0 0x2ff22b50 804399952 r1 0x2ff22b10 804399888 r2 0x20000448 536872008 r3 0x2ff22b50 804399952 r4 0x100010e0 268439776 r5 0x0 0 r6 0x5 5 r7 0x2b67 11111 r8 0x56ce 22222 r9 0x60 96 r10 0xad9c 44444 r11 0x0 0 r12 0x22648680 577013376 r13 0xdeadbeef -559038737 r14 0x1 1 r15 0x2ff22c00 804400128 r16 0x2ff22c08 804400136 r17 0xdeadbeef -559038737 r18 0xdeadbeef -559038737 r19 0xf0806b50 -260019376 r20 0xdeadbeef -559038737 r21 0xdeadbeef -559038737 r22 0xdeadbeef -559038737 r23 0xdeadbeef -559038737 r24 0xdeadbeef -559038737 r25 0xdeadbeef -559038737 r26 0x96c2062c -1765669332 r27 0x88 136 r28 0x200002ed 536871661 r29 0x10000000 268435456 r30 0x3 3 r31 0x2ff22b10 804399888 pc 0x10000690 0x10000690 <main+144> msr 0x200d032 33607730 cnd 0x24648244 610566724 lr 0x10000634 0x10000634 <main+52> cnt 0x0 0 xer 0x20040000 537133056 fpscr 0x0 0 mq 0xdeadbeef -559038737 ------------------------------------------ Output with patch:- ./gdb ~/gdb_tests/bll_core core.13828468 GNU gdb (GDB) 14.0.50.20230221-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc64-ibm-aix7.2.0.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/aditya/gdb_tests/bll_core... Core was generated by `bll_core'. #0 main () at /home/aditya/gdb_tests/bll_core.c:24 24 int length1 = 7; (gdb) info reg r0 0x2ff22b50 804399952 r1 0x2ff22b10 804399888 r2 0x20000448 536872008 r3 0x2ff22b50 804399952 r4 0x100010e0 268439776 r5 0x0 0 r6 0x5 5 r7 0x2b67 11111 r8 0x56ce 22222 r9 0x60 96 r10 0xad9c 44444 r11 0x0 0 r12 0x22648680 577013376 r13 0xdeadbeef 3735928559 r14 0x1 1 r15 0x2ff22c00 804400128 r16 0x2ff22c08 804400136 r17 0xdeadbeef 3735928559 r18 0xdeadbeef 3735928559 r19 0xf0806b50 4034947920 r20 0xdeadbeef 3735928559 r21 0xdeadbeef 3735928559 r22 0xdeadbeef 3735928559 r23 0xdeadbeef 3735928559 r24 0xdeadbeef 3735928559 r25 0xdeadbeef 3735928559 r26 0x96c2062c 2529297964 r27 0x88 136 r28 0x200002ed 536871661 r29 0x10000000 268435456 r30 0x3 3 r31 0x2ff22b10 804399888 pc 0x10000690 0x10000690 <main+144> msr 0x200d032 33607730 cr 0x24648244 610566724 lr 0x10000634 0x10000634 <main+52> ctr 0x0 0 xer 0x20040000 537133056 fpscr 0x0 0 vscr 0x0 0 vrsave 0x1 1 (gdb) info reg $vr0 vr0 {uint128 = 0x14de4f00a6f27802337255053793c0, v4_float = {0x14de4f, 0xa6f278, 0x2337255, 0x53793c0}, v4_int32 = {0x14de4f, 0xa6f278, 0x2337255, 0x53793c0}, v8_int16 = {0x14, 0xde4f, 0xa6, 0xf278, 0x233, 0x7255, 0x537, 0x93c0}, v16_int8 = {0x0, 0x14, 0xde, 0x4f, 0x0, 0xa6, 0xf2, 0x78, 0x2, 0x33, 0x72, 0x55, 0x5, 0x37, 0x93, 0xc0}} (gdb) [-- Attachment #2: 0001-Enable-vector-register-visibility-in-core-file-for-A.patch --] [-- Type: application/octet-stream, Size: 2785 bytes --] From e7e441e524d037fe90fdadf198c210a479b63173 Mon Sep 17 00:00:00 2001 From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> Date: Mon, 13 Mar 2023 07:32:57 -0500 Subject: [PATCH] Enable-vector-register-visibility-in-core-file-for-AIX_binutils This patch will enable vector register visibility when AIX FOLKS do core file analysis. --- bfd/aix5ppc-core.c | 21 +++++++++++++++++++++ bfd/rs6000-core.c | 16 +++++++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/bfd/aix5ppc-core.c b/bfd/aix5ppc-core.c index 0a338ac391b..174b967cdbe 100644 --- a/bfd/aix5ppc-core.c +++ b/bfd/aix5ppc-core.c @@ -142,6 +142,27 @@ xcoff64_core_p (bfd *abfd) sec->filepos = 0; sec->contents = (bfd_byte *)&new_core_hdr->c_flt.r64; + if (core.c_extctx) + { + /* vmx section. */ + flags = SEC_HAS_CONTENTS; + sec = bfd_make_section_anyway_with_flags (abfd, ".aix-vmx", flags); + if (sec == NULL) + return NULL; + sec->size = 560; + sec->vma = 0; + sec->filepos = core.c_extctx; + + /* vmx section. */ + flags = SEC_HAS_CONTENTS; + sec = bfd_make_section_anyway_with_flags (abfd, ".aix-vsx", flags); + if (sec == NULL) + return NULL; + sec->size = 256; + sec->vma = 0; + sec->filepos = core.c_extctx + 584; + } + /* .ldinfo section. To actually find out how long this section is in this particular core dump would require going down the whole list of struct diff --git a/bfd/rs6000-core.c b/bfd/rs6000-core.c index eb096098256..cb8199ae76d 100644 --- a/bfd/rs6000-core.c +++ b/bfd/rs6000-core.c @@ -342,7 +342,7 @@ rs6000coff_core_p (bfd *abfd) /* Values from new and old core structures. */ int c_flag; file_ptr c_stack, c_regoff, c_loader; - bfd_size_type c_size, c_regsize, c_lsize; + bfd_size_type c_size, c_regsize, c_lsize, c_extoff; bfd_vma c_stackend; void *c_regptr; int proc64; @@ -370,6 +370,7 @@ rs6000coff_core_p (bfd *abfd) c_stackend = CNEW_STACKORG (core.new_dump) + c_size; c_lsize = CNEW_LSIZE (core.new_dump); c_loader = CNEW_LOADER (core.new_dump); + c_extoff = core.new_dump.c_extctx; #ifndef BFD64 proc64 = CNEW_PROC64 (core.new_dump); } @@ -517,6 +518,19 @@ rs6000coff_core_p (bfd *abfd) c_regsize, (bfd_vma) 0, c_regoff)) goto fail; + if (c_extoff) + { + if (!make_bfd_asection (abfd, ".aix-vmx", + SEC_HAS_CONTENTS, + 560, (bfd_vma) 0, c_extoff)) + goto fail; + + if (!make_bfd_asection (abfd, ".aix-vsx", + SEC_HAS_CONTENTS, + 256, (bfd_vma) 0, c_extoff + 584)) + goto fail; + } + /* .ldinfo section. To actually find out how long this section is in this particular core dump would require going down the whole list of struct ld_info's. -- 2.38.3
We are pleased to announce that binutils is now online with anoncvs access. With this long-overdue change, it joins gcc and gdb in a more open development model. Please visit http://sourceware.cygnus.com/binutils/ for information pertaining to the cvs archive, and mailing lists associated with binutils. r~
Lee.Smith@arm.com (Lee Smith) writes:
> However, our ELF
> linker (not yet released) handles RELA or any mix of REL and RELA
> (as the ELF standard seems to intend).
The ELF standard intends linkers to handle both?
> >In fact as far as Linux is concerned it probably wouldn't be an especially
> >big deal to introduce RELA in parallel with REL if we wanted to. I think
> >there were rumblings that the ARM SDT compiler was primarily using RELA,
>
> No. ARM only uses REL. We see no advantage to RELA. However, our ELF
> linker (not yet released) handles RELA or any mix of REL and RELA
> (as the ELF standard seems to intend).
>
> AFAIK, Green Hills uses RELA only in its ARM ELF tool chain.
>
> >so we
> >might end up doing it in order to be able to interwork with them. Our
> dynamic
> >linker can be taught to handle binaries with an arbitrary mix of reloc
> types,
> >I think, and I imagine binutils can be made to handle this too if it doesn't
> >already.
The BFD when configured for sh-elf supports both REL and RELA relocation types
although sh-elf-gcc itself only uses REL.
Toshi
At 09:36 PM 4/15/99 +0100, Philip Blundell wrote: [SNIP] >In fact as far as Linux is concerned it probably wouldn't be an especially >big deal to introduce RELA in parallel with REL if we wanted to. I think >there were rumblings that the ARM SDT compiler was primarily using RELA, No. ARM only uses REL. We see no advantage to RELA. However, our ELF linker (not yet released) handles RELA or any mix of REL and RELA (as the ELF standard seems to intend). AFAIK, Green Hills uses RELA only in its ARM ELF tool chain. >so we >might end up doing it in order to be able to interwork with them. Our dynamic >linker can be taught to handle binaries with an arbitrary mix of reloc types, >I think, and I imagine binutils can be made to handle this too if it doesn't >already. > >> 2) >> Whats the R_ARM_THM_XPC22 reloc for? >> >>I dunno. Philip Blundell is on the list. Phil, do you know? > >Actually no. Thumb isn't really my area. I've sent a Cc of this mail to Lee >Smith (who did the original assignment of reloc numbers if I remember right). >Lee, any ideas? Actually, it should be R_ARM_THM_XPC23. It applies to an Architecture V5 variant BL instruction. Consider it a placeholder for now. ---Lee
<<<NEWS FLASH>>> Top Story in Todays Adult news -------------------------------------------------- Pamela Anderson had her breast implants removed last week, to bring her body back to it's "natural state." See our EXCLUSIVE photos of Pamela Anderson's "new look." http://3505021283/Adult/girlies/index.html Internet Adult News ********************************************** 48424
I'd like to publically thank Jason for moving the bfd and gas2 mailing lists over to sourceware.cygnus.com. Among other things, they should now be distributed more quickly. Jason didn't explicitly mention it, but he has moved the old Cygnus-internal mailing list archives over, so the web interface has a long history of messages to the lists. Jason has been doing great work in maintaining sourceware.cygnus.com, which is used by a number of free software projects. As we all know, infrastructure tends to be a thankless job. So although tomorrow he will doubtless return to his obscurity, right now he should bask briefly in the admiration and gratitude of the 50 or so people who read these mailing lists. Cygnus Solutions also deserves our thanks for donating the sourceware.cygnus.com hardware. Ian
Howdy, I've changed the bfd mailing list just a bit. The list address used to be bfd@cygnus.com, it is now bfd@sourceware.cygnus.com. Mail sent to the @cygnus.com address will continue to work for the forseeable future. Everyone who was subscribed to bfd@cygnus.com is subscribed to bfd@sourceware.cygnus.com. The way you subscribe and unsubscribe is different. To get off of this list, send a mail note to bfd-unsubscribe@sourceware.cygnus.com. There is a long explanation about how to unsubscribe with this mailing list software (ezmlm+idx) at http://sourceware.cygnus.com/infra/ezman/ezman-1.html#ss1.4 Those of you who follow the EGCS mailing lists should feel at home; bfd is now using the same list software. There are now web archives for bfd and mbox formatted archives available by ftp: http://sourceware.cygnus.com/ml/bfd/ ftp://sourceware.cygnus.com/pub/binutils/mail-archives/ Please feel free to e-mail me directly with any questions or concerns. Jason
>
> I had this working at least for a little while for the 64 bit MIPS ELF
> target, where the ABI from SGI requires it. However, that target
> never really worked, so I don't know how well mixing REL and RELA
> works.
>
> The support I wrote for MIPS is CPU dependent; the code is in
> elf64-mips.c. But I can't think of any reason why it has to be there.
>
> Most relocation processing is CPU dependent anyhow, probably too much
> so.
>
> However, I would discourage mixing REL and RELA in object files.
> That's just added complexity for no real benefit that I can see.
>
Unfortunately some ABIs require that.
--
H.J. Lu (hjl@gnu.org)
From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 14:15:54 -0700 (PDT) > If REL works now, there is probably no reason to switch to RELA. The > only reason I can think of would be if the compiler can gain an > advantage by splitting instructions which require relocations. It is > sometime possible to make that work with REL instructions anyhow. > > It would also be possible for the linker to support REL and RELA > relocations simultaneously, so there would be no need for a big > cutover. We would just change gas to start generating RELA > relocations, and then after a while we could throw away the REL > support. > > But I don't see a reason to do that if the code works now. Does the linker support mixing REL and RELA on any targets? How CPU depedent is this support? It may be useful to CPUs other than ARM. I had this working at least for a little while for the 64 bit MIPS ELF target, where the ABI from SGI requires it. However, that target never really worked, so I don't know how well mixing REL and RELA works. The support I wrote for MIPS is CPU dependent; the code is in elf64-mips.c. But I can't think of any reason why it has to be there. Most relocation processing is CPU dependent anyhow, probably too much so. However, I would discourage mixing REL and RELA in object files. That's just added complexity for no real benefit that I can see. Ian
> If REL works now, there is probably no reason to switch to RELA. The
> only reason I can think of would be if the compiler can gain an
> advantage by splitting instructions which require relocations. It is
> sometime possible to make that work with REL instructions anyhow.
>
> It would also be possible for the linker to support REL and RELA
> relocations simultaneously, so there would be no need for a big
> cutover. We would just change gas to start generating RELA
> relocations, and then after a while we could throw away the REL
> support.
>
> But I don't see a reason to do that if the code works now.
>
Does the linker support mixing REL and RELA on any targets? How CPU
depedent is this support? It may be useful to CPUs other than ARM.
--
H.J. Lu (hjl@gnu.org)
From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 13:28:50 -0700 (PDT) Ok. You are saying RELA is better than REL. Does it make any senses to use RELA for relocatable object and allow REL for excutable and shared objects? It is possible in principle. In the general case, it is hard. ELF permits a shared library to be compiled normally, not PIC. In such a case, you have to use arbitrary relocations in the shared library. The dynamic linker then runs into the same addend problems as the program linker does. For a PIC shared library, there is normally only a very restricted set of dynamic relocs: a GOT reloc, a JMP reloc, a RELATIVE reloc, and perhaps a few relocs in the .data section. All of these relocs can normally be easily represented using REL relocs. Since in principle the dynamic linker can handle both REL and RELA relocs in the same object, it would be possible in principle to add this optimization for an ELF target which used RELA relocs. I think it would probably be more immediately effective to focus efforts on reducing the total number of dynamic relocations in libc. For example, it has scads of RELATIVE relocs; why? It has GLOB_DAT and JUMP_SLOT relocs for what appear to be internal symbols; it may be possible to eliminate these. > > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. > > Something of which we were entirely unaware of at the time, otherwise we would > have attempted to collaborate in a closer fashion. > > I now recall that I dropped the ball on this one. I saw the request > for the ARM ELF work come in to Cygnus, but I didn't manage to figure > out that it was for a different ABI than the one in H.J.'s snapshots. > If RELA is really desired, can ARM/Linux switch to RELA with a different soname? Binaries using REL should still run ok, just like what we did to libc 5 on x86. If REL works now, there is probably no reason to switch to RELA. The only reason I can think of would be if the compiler can gain an advantage by splitting instructions which require relocations. It is sometime possible to make that work with REL instructions anyhow. It would also be possible for the linker to support REL and RELA relocations simultaneously, so there would be no need for a big cutover. We would just change gas to start generating RELA relocations, and then after a while we could throw away the REL support. But I don't see a reason to do that if the code works now. Ian
From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 13:10:12 -0700 (PDT) While we are on RELA/REL, could someone kindly enough tell me the implementation and performance impacts between RELA and REL, on both static and dynamic objects? I quote bfd/doc/bfdint.texi: In the absence of a supplement, it's easier to work with @samp{Rela} relocations. @samp{Rela} relocations will require more space in object files (but not in executables, except when using dynamic linking). However, this is outweighed by the simplicity of addend handling when using @samp{Rela} relocations. With @samp{Rel} relocations, the addend must be stored in the section contents, which makes relocateable links more complex. For example, consider C code like @code{i = a[1000];} where @samp{a} is a global array. The instructions which load the value of @samp{a[1000]} will most likely use a relocation which refers to the symbol representing @samp{a}, with an addend that gives the offset from the start of @samp{a} to element @samp{1000}. When using @samp{Rel} relocations, that addend must be stored in the instructions themselves. If you are adding support for a RISC chip which uses two or more instructions to load an address, then the addend may not fit in a single instruction, and will have to be somehow split among the instructions. This makes linking awkward, particularly when doing a relocateable link in which the addend may have to be updated. It can be done---the MIPS ELF support does it---but it should be avoided when possible. In short, it's much easier to get the implementation right when using RELA relocations. RELA relocations also permit more flexible handling of split instructions. When the addend has to be gathered together from two or more instructions, the linker has to be able to find them all, which makes it harder to duplicate some and even harder to move them around. This takes away flexibility from the compiler, which may want to be able to move the instructions around freely in order to fill delay slots and the like. A statically linked executable contains no relocation information, so there is no performance difference between REL and RELA relocations. A dynamically linked executable does contain relocation entries. A RELA relocation is 4 bytes larger than a REL relocation (8 bytes larger for a 64 bit target). A REL relocation is 8 bytes, a RELA relocation is 12 bytes (16 and 24 for a 64 bit target). I checked /lib/libc.so.6 on an i386 RedHat 5.2 GNU/Linux system. It has 1914 dynamic relocations. With REL relocations, that takes 15312 bytes, or 3 pages assuming a 4K page size as on the i386. With RELA relocations, it takes 22968 bytes, or 5 pages. So the cost of using RELA relocations is reading 2 disk pages from the cache each time a program is run. (The ix86 uses REL relocations, incidentally.) Actually, it's not so simple, because the dynamic linker does not have to process the jump table relocation entries each time. They can be handled lazily. However, most programs will force at least some jump table relocations to be processed, so it is likely that the dynamic linker will have to read all the dynamic relocations at some point. A complex program may conceivably have enough dynamic relocations to force an extra page to be read, but I doubt that is common. Ian
>Some folks in England put together ARM GNU/Linux, but they took a very >long time to get the copyright stuff done. For some reason that I do >not know, that implementation used REL rather than RELA relocs. Yes, it was all a bit of a mess. In fact (for the benefit of anybody who actually wants the whole gory history) the original implementation that I hacked together for ARM GNU/Linux *did* use RELA relocs. Then Pat and Scott from Corel produced a rather more complete implementation (one that included PIC support) based on the i386 code and hence using REL, and that was the code base that we ended up using. In fact as far as Linux is concerned it probably wouldn't be an especially big deal to introduce RELA in parallel with REL if we wanted to. I think there were rumblings that the ARM SDT compiler was primarily using RELA, so we might end up doing it in order to be able to interwork with them. Our dynamic linker can be taught to handle binaries with an arbitrary mix of reloc types, I think, and I imagine binutils can be made to handle this too if it doesn't already. > 2) > Whats the R_ARM_THM_XPC22 reloc for? > >I dunno. Philip Blundell is on the list. Phil, do you know? Actually no. Thumb isn't really my area. I've sent a Cc of this mail to Lee Smith (who did the original assignment of reloc numbers if I remember right). Lee, any ideas? p.
> > Date: Thu, 15 Apr 1999 14:49:16 -0400 > From: Scott Bambrough <scottb@corelcomputer.com> > > Actually Phil is in England, Pat Beirne and I are in Canada. > > Oops--sorry. > > We chose REL because we did not need the addend. In hindsight I > would choose RELA. > > For the benefit of anybody who is considering an ELF port, please > always use RELA relocs rather than REL relocs. REL relocs work OK for > processors with very simple relocation needs, like an i386 or m68k. > For a RISC processor, they are a real pain. You always need to > support an addend which can support your entire address space, in > order to handle code like this: > char a[10000]; > int foo () { return a[9999]; } > This ought to turn into a reference to the symbol a + 9999, so you > need an addend which can hold a value of 9999, or you get inefficient > code. Ok. You are saying RELA is better than REL. Does it make any senses to use RELA for relocatable object and allow REL for excutable and shared objects? > > > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. > > Something of which we were entirely unaware of at the time, otherwise we would > have attempted to collaborate in a closer fashion. > > I now recall that I dropped the ball on this one. I saw the request > for the ARM ELF work come in to Cygnus, but I didn't manage to figure > out that it was for a different ABI than the one in H.J.'s snapshots. > If RELA is really desired, can ARM/Linux switch to RELA with a different soname? Binaries using REL should still run ok, just like what we did to libc 5 on x86. -- H.J. Lu (hjl@gnu.org)
> Some folks in England put together ARM GNU/Linux, but they took a very
> long time to get the copyright stuff done. For some reason that I do
> not know, that implementation used REL rather than RELA relocs.
>
> In the meantime, Cygnus implemented ARM ELF, using RELA relocs.
>
> It's obviously desirable to have a single ARM ELF ABI, and the best
> choice is probably the one currently being used for GNU/Linux.
> Therefore, when we straightened out the copyright situation, we dumped
> the Cygnus RELA implementation in favour of the GNU/Linux REL
> implementation.
>
While we are on RELA/REL, could someone kindly enough tell me the
implementation and performance impacts between RELA and REL, on
both static and dynamic objects?
Thanks a lot.
--
H.J. Lu (hjl@gnu.org)
Date: Thu, 15 Apr 1999 14:49:16 -0400 From: Scott Bambrough <scottb@corelcomputer.com> Actually Phil is in England, Pat Beirne and I are in Canada. Oops--sorry. We chose REL because we did not need the addend. In hindsight I would choose RELA. For the benefit of anybody who is considering an ELF port, please always use RELA relocs rather than REL relocs. REL relocs work OK for processors with very simple relocation needs, like an i386 or m68k. For a RISC processor, they are a real pain. You always need to support an addend which can support your entire address space, in order to handle code like this: char a[10000]; int foo () { return a[9999]; } This ought to turn into a reference to the symbol a + 9999, so you need an addend which can hold a value of 9999, or you get inefficient code. > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. Something of which we were entirely unaware of at the time, otherwise we would have attempted to collaborate in a closer fashion. I now recall that I dropped the ball on this one. I saw the request for the ARM ELF work come in to Cygnus, but I didn't manage to figure out that it was for a different ABI than the one in H.J.'s snapshots. Ian
Ian Lance Taylor wrote: > > Date: Thu, 15 Apr 1999 10:38:25 -0700 > From: Doug Evans <devans@cygnus.com> > > Two random questions. > > 1) > elfarm-oabi.c uses USE_RELA > elfarm-nabi.c uses USE_REL > That seems rather backwards, doesn't it? > I'd expect a new version of an abi to switch from USE_REL to USE_RELA, > but not the other way around. > [not that it can be changed, but rather ... why the switch?] > > This is my understanding of the situation. If anybody knows that I am > wrong, please correct me. > > The ARM ELF situation is a mess because there were two separate > implementations. > > Some folks in England put together ARM GNU/Linux, but they took a very > long time to get the copyright stuff done. For some reason that I do > not know, that implementation used REL rather than RELA relocs. Actually Phil is in England, Pat Beirne and I are in Canada. And that very long copyright time was due entirely to Corel's legal department. They were a pain in the ass. We chose REL because we did not need the addend. In hindsight I would choose RELA. We did this work over a period of about 6 months when we brought up gcc, binutils, gdb and glibc on the NetWinder. > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. Something of which we were entirely unaware of at the time, otherwise we would have attempted to collaborate in a closer fashion. > It's obviously desirable to have a single ARM ELF ABI, and the best > choice is probably the one currently being used for GNU/Linux. > Therefore, when we straightened out the copyright situation, we dumped > the Cygnus RELA implementation in favour of the GNU/Linux REL > implementation. I don't know about better. Cygnus does pretty good work. It probably has a larger installed base ATM, as the GNU/Linux implementation is used by HJ Lu's 2.9.1.0.xx releases of binutils. I think most of the ARM community uses this rather than the GAS2 snapshots. > Whats the R_ARM_THM_XPC22 reloc for? The docs say it is a Thumb BLX pair. It is a two byte Thumb instruction. It is a relocateable branch instruction, where bits 0-10 encode the 11 most significant bits of the branch offset, and bits 0-10 of the next instruction word encode the least significant bits of the branch offset. There is also a note about it being provisional. The least significant bit of the branch offset must be zero. Scott Bambrough
Date: Thu, 15 Apr 1999 10:38:25 -0700 From: Doug Evans <devans@cygnus.com> Two random questions. 1) elfarm-oabi.c uses USE_RELA elfarm-nabi.c uses USE_REL That seems rather backwards, doesn't it? I'd expect a new version of an abi to switch from USE_REL to USE_RELA, but not the other way around. [not that it can be changed, but rather ... why the switch?] This is my understanding of the situation. If anybody knows that I am wrong, please correct me. The ARM ELF situation is a mess because there were two separate implementations. Some folks in England put together ARM GNU/Linux, but they took a very long time to get the copyright stuff done. For some reason that I do not know, that implementation used REL rather than RELA relocs. In the meantime, Cygnus implemented ARM ELF, using RELA relocs. It's obviously desirable to have a single ARM ELF ABI, and the best choice is probably the one currently being used for GNU/Linux. Therefore, when we straightened out the copyright situation, we dumped the Cygnus RELA implementation in favour of the GNU/Linux REL implementation. 2) Whats the R_ARM_THM_XPC22 reloc for? I dunno. Philip Blundell is on the list. Phil, do you know? Ian
Two random questions. 1) elfarm-oabi.c uses USE_RELA elfarm-nabi.c uses USE_REL That seems rather backwards, doesn't it? I'd expect a new version of an abi to switch from USE_REL to USE_RELA, but not the other way around. [not that it can be changed, but rather ... why the switch?] 2) Whats the R_ARM_THM_XPC22 reloc for?
Hi, I reported this problem already with bfd in binutils-2.9.1 and gdb-4.17; as it is still present in gdb-4.18, I'm re-posting a patch. manfred On Tue, 23 February 1999, 17:20:23, manfred@s-direktnet.de wrote: > This small patch fixes a bug I observed while running gdb-4.17 > on a mips-sgi-irix5.3 system. Since the debuggee's debug info > was larger than the system's virtual memory was able to provide, > the "goto error_return" in bfd/elf32-mips.c:_bfd_mips_elf_read_ecoff_info > got executed, which in turn tries to cleanup allocated memory. > Unfortunately, it's simply checking probably unitialized > memory to decide whether it should. 1999-04-14 Manfred Hollstein <mhollstein@cygnus.com> * elf32-mips.c (_bfd_mips_elf_read_ecoff_info): Set all fields to 0 which may cause erroneous calls to free when "goto error_return" is executed. diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el gdb-4.18.orig/bfd/elf32-mips.c gdb-4.18/bfd/elf32-mips.c --- gdb-4.18.orig/bfd/elf32-mips.c Wed Apr 7 22:57:07 1999 +++ gdb-4.18/bfd/elf32-mips.c Wed Apr 14 15:13:27 1999 @@ -3058,6 +3058,17 @@ _bfd_mips_elf_read_ecoff_info (abfd, sec /* The symbolic header contains absolute file offsets and sizes to read. */ + debug->line = 0; + debug->external_dnr = 0; + debug->external_pdr = 0; + debug->external_sym = 0; + debug->external_opt = 0; + debug->external_aux = 0; + debug->ss = 0; + debug->ssext = 0; + debug->external_fdr = 0; + debug->external_rfd = 0; + debug->external_ext = 0; #define READ(ptr, offset, count, size, type) \ if (symhdr->count == 0) \ debug->ptr = NULL; \ -- Manfred Hollstein If you have any questions about GNU software: EMAIL: <mhollstein@cygnus.com> or <manfred.h@gmx.net> WWW: < http://home.t-online.de/home/manfred-h/ > PGP: < http://home.t-online.de/home/manfred-h/manfred.hATgmx.net.asc >
Date: Mon, 12 Apr 1999 15:30:54 -0500 (CDT) From: Mumit Khan <khan@xraylith.wisc.edu> btw, I always thought that the Makefiles were setup to do the `make headers' automatically in bfd. Guess not. No, you only get an automatic `make headers' if you configure with --enable-maintainer-mode. If you do that, you must also make sure you have correct versions of autoconf, automake, and gettext in your PATH. Ian
I've been working with DJ on creating an updated patch. I'm convinced that Menehunes got to at least one copy, because there's no way that some of the problems that are inarguably there could have gotten there without a time warp :-). Anyway, expect a new tarball (over the old one) with these and a number of other problems fixed in a few days. (Everythings fairly straightforward except for another go-around on %^&#$%^^&*()&*(%^&^%*& .idata.) (Mumit: I believe #2 is fixed in what you have, but only in the base files; in this case automake needs to be run to move the change up from Makefile.am to Makefile.in.) I'll send email when it's done. Donn Mumit Khan wrote: > > Hi Donn, > > Ran into a few nits when building for Cygwin -- > > 1. you mention that you've *put back* the .bss handling, but it's missing > from the post-patched ld/scripttempl/pe.sc. I just put it in my hand. > > 2. bfd/Makefile.in needs peigen.lo as target. Trivial obviously. > > 3. the $ENTRY in pe.sc expands to __mainCRTStartup, but Cygwin provides > _mainCRTStartup. Trivial to fix/make consistent of course. > > The final executable doesn't work yet, but that I did expect. I'll do > some digging to see why it's not loading correctly (under Cygwin or > Mingw which uses MS runtime). > > btw, I always thought that the Makefiles were setup to do the `make > headers' automatically in bfd. Guess not. > > Regards, > Mumit -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 ===================================================
Live sincity XXXClub pictures and videos. Featuring exclusive photos of... - Tommy Lee and Heather Locklear (before Pamela Anderson) - A Calista Flockheart strip tease (aka Ally McBeal) - Plus MUCH MUCH more http://38.150.73.20/boots/index.html ****************************************************************** 83687