[PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Julian Brown]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Hi,

This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
PLT entries are written in ARM mode, but previously they were being 
called in thumb mode, with their address incorrectly offset by -4 
(PLT_THUMB_STUB_SIZE).

Now, the target address has been corrected and the thumb BL instruction 
is rewritten as BLX to perform the mode switch before attempting to 
execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
is only targeted at armv5t+, this should always be OK.)

The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
also been rewritten as PLT_THUMB_STUB_SIZE.

OK to apply?

Julian

[-- Attachment #2: patch-3 --]
[-- Type: text/plain, Size: 1191 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.22
diff -c -p -r1.22 elf32-arm.c
*** bfd/elf32-arm.c	11 Feb 2005 16:41:09 -0000	1.22
--- bfd/elf32-arm.c	16 Mar 2005 12:38:29 -0000
*************** elf32_arm_final_link_relocate (reloc_how
*** 2692,2699 ****
  	    value = (splt->output_section->vma
  		     + splt->output_offset
  		     + h->plt.offset);
! 	    /* Target the Thumb stub before the ARM PLT entry.  */
! 	    value -= 4;
  	  }
  
  	relocation = value + signed_addend;
--- 2692,2708 ----
  	    value = (splt->output_section->vma
  		     + splt->output_offset
  		     + h->plt.offset);
! 	    if (globals->symbian_p)
! 	      {
! 		/* On SymbianOS, we are guaranteed to be using at least ARMv5t.
! 		   Convert the BL to a BLX instruction to call the ARM-mode PLT
! 		   entry.  */
! 		if ((lower_insn & (0x3 << 11)) == 0x3 << 11)
! 		  lower_insn = (lower_insn & ~(0x3 << 11)) | 0x1 << 11;
! 	      }
! 	    else
! 	      /* Target the Thumb stub before the ARM PLT entry.  */
! 	      value -= PLT_THUMB_STUB_SIZE;
  	  }
  
  	relocation = value + signed_addend;

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 14:17, Julian Brown wrote:
> Hi,
> 
> This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
> PLT entries are written in ARM mode, but previously they were being 
> called in thumb mode, with their address incorrectly offset by -4 
> (PLT_THUMB_STUB_SIZE).
> 
> Now, the target address has been corrected and the thumb BL instruction 
> is rewritten as BLX to perform the mode switch before attempting to 
> execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
> is only targeted at armv5t+, this should always be OK.)
> 
> The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
> also been rewritten as PLT_THUMB_STUB_SIZE.
> 
> OK to apply?

This sounds like a hack.  I'd much rather a generic solution were found
(and which permitted the blx optimization if available).

R.

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Daniel Jacobowitz]

On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote:
> On Wed, 2005-03-16 at 14:17, Julian Brown wrote:
> > Hi,
> > 
> > This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
> > PLT entries are written in ARM mode, but previously they were being 
> > called in thumb mode, with their address incorrectly offset by -4 
> > (PLT_THUMB_STUB_SIZE).
> > 
> > Now, the target address has been corrected and the thumb BL instruction 
> > is rewritten as BLX to perform the mode switch before attempting to 
> > execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
> > is only targeted at armv5t+, this should always be OK.)
> > 
> > The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
> > also been rewritten as PLT_THUMB_STUB_SIZE.
> > 
> > OK to apply?
> 
> This sounds like a hack.  I'd much rather a generic solution were found
> (and which permitted the blx optimization if available).

The SymbianOS bits sound generally right to me.  The fact that the -4
bias is currently included is just a bug; that's from the code to
generate a Thumb header on PLT entries, which is already disabled
for SymbianOS.

OTOH, it may be missing some error checks - what if it's _not_ a BL? 
Could we reach here?

Ideally, yes, I want to do this transformation on non-SymbianOS too.
But, we don't have a clear indicator saying "yes it is save to generate
blx" yet.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Julian Brown]

Daniel Jacobowitz wrote:
> On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote:
> 
>>On Wed, 2005-03-16 at 14:17, Julian Brown wrote:
>>
>>>Hi,
>>>
>>>This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
>>>PLT entries are written in ARM mode, but previously they were being 
>>>called in thumb mode, with their address incorrectly offset by -4 
>>>(PLT_THUMB_STUB_SIZE).
>>>
>>>Now, the target address has been corrected and the thumb BL instruction 
>>>is rewritten as BLX to perform the mode switch before attempting to 
>>>execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
>>>is only targeted at armv5t+, this should always be OK.)
>>>
>>>The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
>>>also been rewritten as PLT_THUMB_STUB_SIZE.
>>>
>>>OK to apply?
>>
>>This sounds like a hack.  I'd much rather a generic solution were found
>>(and which permitted the blx optimization if available).
> 
> 
> The SymbianOS bits sound generally right to me.  The fact that the -4
> bias is currently included is just a bug; that's from the code to
> generate a Thumb header on PLT entries, which is already disabled
> for SymbianOS.
> 
> OTOH, it may be missing some error checks - what if it's _not_ a BL? 
> Could we reach here?

I assumed not: this is an R_ARM_THM_PC22, alias R_ARM_THM_CALL 
relocation. Can that sensibly point at anything else?

Would it be better to add a --target-arch (or something) flag to 
binutils at this point? That would tidy up a previous patch of mine, 
too. I don't know if any other targets have, or need, such an option.

Julian

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 14:42, Daniel Jacobowitz wrote:
> On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote:
> > On Wed, 2005-03-16 at 14:17, Julian Brown wrote:
> > > Hi,
> > > 
> > > This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
> > > PLT entries are written in ARM mode, but previously they were being 
> > > called in thumb mode, with their address incorrectly offset by -4 
> > > (PLT_THUMB_STUB_SIZE).
> > > 
> > > Now, the target address has been corrected and the thumb BL instruction 
> > > is rewritten as BLX to perform the mode switch before attempting to 
> > > execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
> > > is only targeted at armv5t+, this should always be OK.)
> > > 
> > > The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
> > > also been rewritten as PLT_THUMB_STUB_SIZE.
> > > 
> > > OK to apply?
> > 
> > This sounds like a hack.  I'd much rather a generic solution were found
> > (and which permitted the blx optimization if available).
> 
> The SymbianOS bits sound generally right to me.  The fact that the -4
> bias is currently included is just a bug; that's from the code to
> generate a Thumb header on PLT entries, which is already disabled
> for SymbianOS.
> 

I'll have to look at that bit in further detail.

> OTOH, it may be missing some error checks - what if it's _not_ a BL? 
> Could we reach here?
> 

Possibly.  Tail call?  Doesn't happen in GCC, but another compiler might
do it.

> Ideally, yes, I want to do this transformation on non-SymbianOS too.
> But, we don't have a clear indicator saying "yes it is save to generate
> blx" yet.

We shouldn't be testing SymbianOS here.  We should be testing whether
blx is available.  If it is, then use the blx sequence; if not, then use
a further trampoline that switches to ARM state and then jumps to the
PLT.  Other code in the initialization sequence can then mark that
symbianos always has blx available.

R.

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 14:49, Julian Brown wrote:
> Daniel Jacobowitz wrote:
> > On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote:
> > 
> >>On Wed, 2005-03-16 at 14:17, Julian Brown wrote:
> >>
> >>>Hi,
> >>>
> >>>This patch fixes calls made from thumb mode via the PLT on SymbianOS. 
> >>>PLT entries are written in ARM mode, but previously they were being 
> >>>called in thumb mode, with their address incorrectly offset by -4 
> >>>(PLT_THUMB_STUB_SIZE).
> >>>
> >>>Now, the target address has been corrected and the thumb BL instruction 
> >>>is rewritten as BLX to perform the mode switch before attempting to 
> >>>execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS 
> >>>is only targeted at armv5t+, this should always be OK.)
> >>>
> >>>The hardwired "4" for the thumb stub size on non-SymbianOS targets has 
> >>>also been rewritten as PLT_THUMB_STUB_SIZE.
> >>>
> >>>OK to apply?
> >>
> >>This sounds like a hack.  I'd much rather a generic solution were found
> >>(and which permitted the blx optimization if available).
> > 
> > 
> > The SymbianOS bits sound generally right to me.  The fact that the -4
> > bias is currently included is just a bug; that's from the code to
> > generate a Thumb header on PLT entries, which is already disabled
> > for SymbianOS.
> > 
> > OTOH, it may be missing some error checks - what if it's _not_ a BL? 
> > Could we reach here?
> 
> I assumed not: this is an R_ARM_THM_PC22, alias R_ARM_THM_CALL 
> relocation. Can that sensibly point at anything else?
> 

Ah!  Yep, that can only apply to a thumb BL instruction.

> Would it be better to add a --target-arch (or something) flag to 
> binutils at this point? That would tidy up a previous patch of mine, 
> too. I don't know if any other targets have, or need, such an option.

Yep, I think that would be a good idea.  Ideally we'd want a linker
command-line option as well, but a configuration option would be a good
first step.

R.

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Julian Brown]

Richard Earnshaw wrote:
> On Wed, 2005-03-16 at 14:49, Julian Brown wrote:
> 
>>Would it be better to add a --target-arch (or something) flag to 
>>binutils at this point? That would tidy up a previous patch of mine, 
>>too. I don't know if any other targets have, or need, such an option.
> 
> 
> Yep, I think that would be a good idea.  Ideally we'd want a linker
> command-line option as well, but a configuration option would be a good
> first step.

Sorry, cross-purposes: a linker command-line option was more like what I 
had in mind. I'll see what I can come up with.

Julian

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Ian Lance Taylor]

Julian Brown <julian@codesourcery.com> writes:

> Would it be better to add a --target-arch (or something) flag to
> binutils at this point? That would tidy up a previous patch of mine,
> too. I don't know if any other targets have, or need, such an option.

I think the linker should support a command line option to do what
OUTPUT_ARCH does in a linker script.  Perhaps the thing to do would be
to redefine the -A/--architecture option, which is only used for the
Intel i960.  -A currently affects library search order, which we would
not want for the new option.    However, I doubt that anybody uses the
i960 any more, and even if they do, they probably don't use the -A
option.

Ian

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote:
> Julian Brown <julian@codesourcery.com> writes:
> 
> > Would it be better to add a --target-arch (or something) flag to
> > binutils at this point? That would tidy up a previous patch of mine,
> > too. I don't know if any other targets have, or need, such an option.
> 
> I think the linker should support a command line option to do what
> OUTPUT_ARCH does in a linker script.  

I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH
does.  

It appears that OUTPUT_ARCH uses bfd variant names, but the problem is
that in the past this has worked by (ab)using bits in the ELF header
which simply aren't available in the EABI.  There's also a potential
disaster in this area of the exploding cross-product: the core
architecture is just one dimension in the matrix.

> Perhaps the thing to do would be
> to redefine the -A/--architecture option, which is only used for the
> Intel i960.  -A currently affects library search order, which we would
> not want for the new option.    However, I doubt that anybody uses the
> i960 any more, and even if they do, they probably don't use the -A
> option.

I'd really like to be able to just pass -march through from the
compiler.  Anything solution that needs any remapping beyond a common
prefix substitution in a gcc spec file is just a disaster waiting to
happen.

R.

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Ian Lance Taylor]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote:
> > Julian Brown <julian@codesourcery.com> writes:
> > 
> > > Would it be better to add a --target-arch (or something) flag to
> > > binutils at this point? That would tidy up a previous patch of mine,
> > > too. I don't know if any other targets have, or need, such an option.
> > 
> > I think the linker should support a command line option to do what
> > OUTPUT_ARCH does in a linker script.  
> 
> I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH
> does.  
> 
> It appears that OUTPUT_ARCH uses bfd variant names, but the problem is
> that in the past this has worked by (ab)using bits in the ELF header
> which simply aren't available in the EABI.  There's also a potential
> disaster in this area of the exploding cross-product: the core
> architecture is just one dimension in the matrix.

OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
course that list can be adjusted.

I think the ELF header issue is irrelevant here.  That is a matter of
how the architecture is represented in the output file.  It's
obviously convenient to represent the architecture correctly in the
output file so that it can be recognized by something reading the
file, but that is not a requirement, and the information does not have
to be in the ELF header.

> > Perhaps the thing to do would be
> > to redefine the -A/--architecture option, which is only used for the
> > Intel i960.  -A currently affects library search order, which we would
> > not want for the new option.    However, I doubt that anybody uses the
> > i960 any more, and even if they do, they probably don't use the -A
> > option.
> 
> I'd really like to be able to just pass -march through from the
> compiler.  Anything solution that needs any remapping beyond a common
> prefix substitution in a gcc spec file is just a disaster waiting to
> happen.

The linker already has a -m option, used to specify the emulation to
use, so -march itself would not work.  But I wouldn't be opposed to
adding an option which just set the machine name.  I would have to be
convinced about adding something which bypassed the existing BFD
architecture/machine machinery.

Ian

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 16:39, Ian Lance Taylor wrote:

> OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
> one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
> course that list can be adjusted.
> 

The current attributes proposal for the ABI lists 27 separate
attributes, giving rise to a theoretical 10^14 possible variants.  In
practice the number of realistic variants is much smaller than this, but
it's still much larger than can be listed explicitly in an arch_info
struct.

> I think the ELF header issue is irrelevant here.  That is a matter of
> how the architecture is represented in the output file.  It's
> obviously convenient to represent the architecture correctly in the
> output file so that it can be recognized by something reading the
> file, but that is not a requirement, and the information does not have
> to be in the ELF header.

The architecture is just one factor here.  Maybe the most important one,
but still just one of many.

> 
> > > Perhaps the thing to do would be
> > > to redefine the -A/--architecture option, which is only used for the
> > > Intel i960.  -A currently affects library search order, which we would
> > > not want for the new option.    However, I doubt that anybody uses the
> > > i960 any more, and even if they do, they probably don't use the -A
> > > option.
> > 
> > I'd really like to be able to just pass -march through from the
> > compiler.  Anything solution that needs any remapping beyond a common
> > prefix substitution in a gcc spec file is just a disaster waiting to
> > happen.
> 
> The linker already has a -m option, used to specify the emulation to
> use, so -march itself would not work.  But I wouldn't be opposed to
> adding an option which just set the machine name.  I would have to be
> convinced about adding something which bypassed the existing BFD
> architecture/machine machinery.

A trivial mapping of -march=xxx to -foobar=xxx is not a problem.  It's
mapping xxx to yyy that must be avoided.  We used to try to do that in
the assembler and it wasn't maintainable.

R. 

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Ian Lance Taylor]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> On Wed, 2005-03-16 at 16:39, Ian Lance Taylor wrote:
> 
> > OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
> > one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
> > course that list can be adjusted.
> > 
> 
> The current attributes proposal for the ABI lists 27 separate
> attributes, giving rise to a theoretical 10^14 possible variants.  In
> practice the number of realistic variants is much smaller than this, but
> it's still much larger than can be listed explicitly in an arch_info
> struct.

I guess I misunderstood the issue.  I didn't realize that it was
necessary to support a set of different attributes.  I guess I don't
understand why -march was brought up---march in gcc doesn't take a set
of attributes.

Of course a set of attributes could be done in BFD by using the
machine number as a bitfield, but that is probably not the way to go.
The general usage in BFD architecture usage is to focus on existing
processors, and sometimes to add nonexistent intermediate processors
for convenience (e.g., bfd/cpu-sh.c).

Ian

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Richard Earnshaw]

On Wed, 2005-03-16 at 17:33, Ian Lance Taylor wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> 
> > On Wed, 2005-03-16 at 16:39, Ian Lance Taylor wrote:
> > 
> > > OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
> > > one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
> > > course that list can be adjusted.
> > > 
> > 
> > The current attributes proposal for the ABI lists 27 separate
> > attributes, giving rise to a theoretical 10^14 possible variants.  In
> > practice the number of realistic variants is much smaller than this, but
> > it's still much larger than can be listed explicitly in an arch_info
> > struct.
> 
> I guess I misunderstood the issue.  I didn't realize that it was
> necessary to support a set of different attributes.  I guess I don't
> understand why -march was brought up---march in gcc doesn't take a set
> of attributes.
> 

-march was brought up because *in this particular case* it's the
attribute that we are interested in: does the target architecture have
the blx instruction?  So it's true that *in this particular case* we
could solve the problem in the info_arch vector: but we can't solve the
general problem that way -- it requires more a complex solution.

> Of course a set of attributes could be done in BFD by using the
> machine number as a bitfield, but that is probably not the way to go.

You'd need something like 68 bits to fully describe the 27 attributes.

R.

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc)

[Julian Brown]

Richard Earnshaw wrote:
> On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote:
> 
>>Julian Brown <julian@codesourcery.com> writes:
>>
>>
>>>Would it be better to add a --target-arch (or something) flag to
>>>binutils at this point? That would tidy up a previous patch of mine,
>>>too. I don't know if any other targets have, or need, such an option.
>>
>>I think the linker should support a command line option to do what
>>OUTPUT_ARCH does in a linker script.  
> 
> 
> I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH
> does.  
> 
> It appears that OUTPUT_ARCH uses bfd variant names, but the problem is
> that in the past this has worked by (ab)using bits in the ELF header
> which simply aren't available in the EABI.  There's also a potential
> disaster in this area of the exploding cross-product: the core
> architecture is just one dimension in the matrix.
> 
> 
>>Perhaps the thing to do would be
>>to redefine the -A/--architecture option, which is only used for the
>>Intel i960.  -A currently affects library search order, which we would
>>not want for the new option.    However, I doubt that anybody uses the
>>i960 any more, and even if they do, they probably don't use the -A
>>option.
> 
> 
> I'd really like to be able to just pass -march through from the
> compiler.  Anything solution that needs any remapping beyond a common
> prefix substitution in a gcc spec file is just a disaster waiting to
> happen.

I've been working on a new patch, but now I come to think about it I'm 
unsure what the conclusion of this discussion was, so I may be just 
heading towards a dead-end. I think my confusion arises from there being 
two different things being discussed here: the behaviour of the linker 
(which relocations do what), and the representation of the architecture 
in the input and output files. As far as I can tell, the ARM EABI build 
attributes seem to be primarily concerned with the latter, and not so 
useful for the former. (And besides which, they aren't implemented yet, 
and I'm probably not the best person to do that.)

It seems to be quite easy to alter the behaviour of -A/--architecture to 
do the same as the linker script OUTPUT_ARCH, then use that information 
from the output bfd to control the linker's interpretation of 
R_ARM_THM_CALL. (It also suffices to control the behaviour of 
R_ARM_V4BX, by seeing if the current arch is armv4. Previous patch here:

   http://sourceware.org/ml/binutils/2005-01/msg00479.html )

But OUTPUT_ARCH also affects the output file, which isn't necessarily 
what we want if we're only trying to affect linker behaviour (and 
indeed, the build attributes are probably better for that).

So the choices as I see it are as follows:

   (1) Add a seperate "-march=xyz -> --foobar=xyz" style passthrough.
       This unfortunately gives ld and bfd a new and different concept of
       what an architecture is.

   (2) Use existing OUTPUT_ARCH machinery with a redefined --architecture
       option, and:
     (a) Don't use any automatic architecture passthrough from gcc, or
     (b) Extend bfd machine table with all the architectures gcc knows
         about, to enable .

   (3) Forget this for now, and use my original SymbianOS-specific patch.

I'm inclined towards 2a or 3. (e.g. for 2a, use explicit 
-Wl,--architecture,xyz when necessary). Comments?

Julian

Question!

[NK]

Hello all,

I have question regarding LD, I have modified the SEARCH_DIR path in
the ld using --with-lib-path during configuration. I want ld to look
into new path for libraries I have specified.

Interestingly it is going into /usr/bin and accessing libc.so from
there.. and because I have modified the SEARCH_DIR so it is not going
into /lib and unable to find ld-linux.so.2, but going in /usr/lib;
this is something I don't want.

So my question is even if I have modified the SEARCH_DIR in ld why it
is going into /usr/lib (path is not there)? Is there a way to prevent
that... or it is hard coded somewhere in the code. I have all libc .so
in path I have specified also, but not picking from there...

Thanks a lot in advance. 
-nk

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc)

[Paul Brook]

>    (1) Add a seperate "-march=xyz -> --foobar=xyz" style passthrough.
>        This unfortunately gives ld and bfd a new and different concept of
>        what an architecture is.
>
>    (2) Use existing OUTPUT_ARCH machinery with a redefined --architecture
>        option, and:
>      (a) Don't use any automatic architecture passthrough from gcc, or
>      (b) Extend bfd machine table with all the architectures gcc knows
>          about, to enable .
>    (3) Forget this for now, and use my original SymbianOS-specific patch.
>
> I'm inclined towards 2a or 3. (e.g. for 2a, use explicit
> -Wl,--architecture,xyz when necessary). Comments?

I think passing though the gcc -march= and -mcpu= options (you need both) 
would be a waste of effort.  This should be mostly redundant once we 
implement build proper object build attributes.

Paul

Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS

[Julian Brown]

Richard Earnshaw wrote:
> On Wed, 2005-03-16 at 17:33, Ian Lance Taylor wrote:
> 
>>Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
>>
>>
>>>On Wed, 2005-03-16 at 16:39, Ian Lance Taylor wrote:
>>>
>>>
>>>>OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
>>>>one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
>>>>course that list can be adjusted.
>>>>
>>>
>>>The current attributes proposal for the ABI lists 27 separate
>>>attributes, giving rise to a theoretical 10^14 possible variants.  In
>>>practice the number of realistic variants is much smaller than this, but
>>>it's still much larger than can be listed explicitly in an arch_info
>>>struct.
>>
>>I guess I misunderstood the issue.  I didn't realize that it was
>>necessary to support a set of different attributes.  I guess I don't
>>understand why -march was brought up---march in gcc doesn't take a set
>>of attributes.
>>
> 
> -march was brought up because *in this particular case* it's the
> attribute that we are interested in: does the target architecture have
> the blx instruction?  So it's true that *in this particular case* we
> could solve the problem in the info_arch vector: but we can't solve the
> general problem that way -- it requires more a complex solution.
> 
> 
>>Of course a set of attributes could be done in BFD by using the
>>machine number as a bitfield, but that is probably not the way to go.
> 
> 
> You'd need something like 68 bits to fully describe the 27 attributes.

Implementing the whole of the build attributes machinery is going to be 
a lot of work. Richard, do you have a suggestion for a short-term plan 
for fixing the problem in hand which would be acceptible for you?

After experimenting with the OUTPUT_ARCH machinery, I've decided it 
probably isn't the right way of solving this (the treatment of the 
R_ARM_THM_CALL relocation at link-time). There are just too many fiddly 
corners involved - e.g. bfd_arm_merge_machines will happily override the 
OUTPUT_ARCH set in a linker script (or from the command-line, after 
patching).

Cheers,

Julian

Re: Question!

[Nick Clifton]

Hi NK,

> I have question regarding LD, I have modified the SEARCH_DIR path in
> the ld using --with-lib-path during configuration. I want ld to look
> into new path for libraries I have specified.
> 
> Interestingly it is going into /usr/bin and accessing libc.so from
> there.. and because I have modified the SEARCH_DIR so it is not going
> into /lib and unable to find ld-linux.so.2, but going in /usr/lib;
> this is something I don't want.
> 
> So my question is even if I have modified the SEARCH_DIR in ld why it
> is going into /usr/lib (path is not there)? Is there a way to prevent
> that... or it is hard coded somewhere in the code. I have all libc .so
> in path I have specified also, but not picking from there...

You may well have encountered a bug in the linker.  The --with-lib-path 
configure switch is supposed to control where the linker will look for 
libraries.

If you can reproduce this problem using the latest sources in the 
binutils CVS repository then please submit a bug report, including a 
small working example of the problem, via the binutils bugzilla system at:

   http://sources.redhat.com/bugzilla/

Cheers
   Nick