public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
* arm questions
@ 1999-04-15 10:38 Doug Evans
  1999-04-15 11:01 ` Ian Lance Taylor
  0 siblings, 1 reply; 15+ messages in thread
From: Doug Evans @ 1999-04-15 10:38 UTC (permalink / raw)
  To: bfd

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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 10:38 arm questions Doug Evans
@ 1999-04-15 11:01 ` Ian Lance Taylor
  1999-04-15 11:31   ` Scott Bambrough
                     ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Ian Lance Taylor @ 1999-04-15 11:01 UTC (permalink / raw)
  To: devans; +Cc: bfd

   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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 11:01 ` Ian Lance Taylor
@ 1999-04-15 11:31   ` Scott Bambrough
  1999-04-15 11:47     ` Ian Lance Taylor
  1999-04-15 13:10   ` arm questions H.J. Lu
  1999-04-15 13:36   ` Philip Blundell
  2 siblings, 1 reply; 15+ messages in thread
From: Scott Bambrough @ 1999-04-15 11:31 UTC (permalink / raw)
  To: bfd

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 11:31   ` Scott Bambrough
@ 1999-04-15 11:47     ` Ian Lance Taylor
  1999-04-15 13:29       ` H.J. Lu
  0 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 1999-04-15 11:47 UTC (permalink / raw)
  To: scottb; +Cc: bfd

   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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 11:01 ` Ian Lance Taylor
  1999-04-15 11:31   ` Scott Bambrough
@ 1999-04-15 13:10   ` H.J. Lu
  1999-04-15 13:45     ` Ian Lance Taylor
  1999-04-15 13:36   ` Philip Blundell
  2 siblings, 1 reply; 15+ messages in thread
From: H.J. Lu @ 1999-04-15 13:10 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: devans, bfd

> 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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 11:47     ` Ian Lance Taylor
@ 1999-04-15 13:29       ` H.J. Lu
  1999-04-15 13:59         ` Ian Lance Taylor
  0 siblings, 1 reply; 15+ messages in thread
From: H.J. Lu @ 1999-04-15 13:29 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: scottb, bfd

> 
>    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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 11:01 ` Ian Lance Taylor
  1999-04-15 11:31   ` Scott Bambrough
  1999-04-15 13:10   ` arm questions H.J. Lu
@ 1999-04-15 13:36   ` Philip Blundell
  1999-04-16  0:43     ` Lee Smith
       [not found]     ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>
  2 siblings, 2 replies; 15+ messages in thread
From: Philip Blundell @ 1999-04-15 13:36 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: devans, bfd, lee.smith

>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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 13:10   ` arm questions H.J. Lu
@ 1999-04-15 13:45     ` Ian Lance Taylor
  0 siblings, 0 replies; 15+ messages in thread
From: Ian Lance Taylor @ 1999-04-15 13:45 UTC (permalink / raw)
  To: hjl; +Cc: bfd

   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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 13:29       ` H.J. Lu
@ 1999-04-15 13:59         ` Ian Lance Taylor
  1999-04-15 14:15           ` Mixing REL and RELA H.J. Lu
  0 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 1999-04-15 13:59 UTC (permalink / raw)
  To: hjl; +Cc: bfd

   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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Mixing REL and RELA
  1999-04-15 13:59         ` Ian Lance Taylor
@ 1999-04-15 14:15           ` H.J. Lu
  1999-04-15 14:21             ` Ian Lance Taylor
  0 siblings, 1 reply; 15+ messages in thread
From: H.J. Lu @ 1999-04-15 14:15 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: bfd

> 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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Mixing REL and RELA
  1999-04-15 14:15           ` Mixing REL and RELA H.J. Lu
@ 1999-04-15 14:21             ` Ian Lance Taylor
  1999-04-15 14:28               ` H.J. Lu
  0 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 1999-04-15 14:21 UTC (permalink / raw)
  To: hjl; +Cc: bfd

   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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Mixing REL and RELA
  1999-04-15 14:21             ` Ian Lance Taylor
@ 1999-04-15 14:28               ` H.J. Lu
  0 siblings, 0 replies; 15+ messages in thread
From: H.J. Lu @ 1999-04-15 14:28 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: bfd

> 
> 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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-15 13:36   ` Philip Blundell
@ 1999-04-16  0:43     ` Lee Smith
  1999-04-16  3:21       ` Toshi Morita
       [not found]     ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>
  1 sibling, 1 reply; 15+ messages in thread
From: Lee Smith @ 1999-04-16  0:43 UTC (permalink / raw)
  To: Philip Blundell, Ian Lance Taylor; +Cc: devans, bfd

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
  1999-04-16  0:43     ` Lee Smith
@ 1999-04-16  3:21       ` Toshi Morita
  0 siblings, 0 replies; 15+ messages in thread
From: Toshi Morita @ 1999-04-16  3:21 UTC (permalink / raw)
  To: bfd

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: arm questions
       [not found]     ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>
@ 1999-04-18 17:10       ` Doug Evans
  0 siblings, 0 replies; 15+ messages in thread
From: Doug Evans @ 1999-04-18 17:10 UTC (permalink / raw)
  To: Lee Smith; +Cc: bfd

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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~1999-04-18 17:10 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-15 10:38 arm questions Doug Evans
1999-04-15 11:01 ` Ian Lance Taylor
1999-04-15 11:31   ` Scott Bambrough
1999-04-15 11:47     ` Ian Lance Taylor
1999-04-15 13:29       ` H.J. Lu
1999-04-15 13:59         ` Ian Lance Taylor
1999-04-15 14:15           ` Mixing REL and RELA H.J. Lu
1999-04-15 14:21             ` Ian Lance Taylor
1999-04-15 14:28               ` H.J. Lu
1999-04-15 13:10   ` arm questions H.J. Lu
1999-04-15 13:45     ` Ian Lance Taylor
1999-04-15 13:36   ` Philip Blundell
1999-04-16  0:43     ` Lee Smith
1999-04-16  3:21       ` Toshi Morita
     [not found]     ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>
1999-04-18 17:10       ` Doug Evans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).