Hi,
On Wed, Sep 22, 2010 at 2:04 PM, Loïc Minier wrote:
> On Wed, Sep 22, 2010, Dave Martin wrote:
>> I'm not a toolchain expert, so I'm happy to be overridden... but my
>> _guess_ is:
>>
>> I think that in practice (at least on arm) cc -fPIC = cc -fPIE, and ld
>> -pie just forces ld to generate
On Wed, Sep 22, 2010, Dave Martin wrote:
> I'm not a toolchain expert, so I'm happy to be overridden... but my
> _guess_ is:
>
> I think that in practice (at least on arm) cc -fPIC = cc -fPIE, and ld
> -pie just forces ld to generate PIC veneers (as for -shared). Beyond
> this, I think ld -shared
Hi,
On Wed, Sep 22, 2010 at 1:38 PM, Loïc Minier wrote:
> On Wed, Sep 22, 2010, Dave Martin wrote:
>> This tells the compiler to generate PIC code, but it doesn't tell the
>> linker to generate PIC output... which matters if the linker needs to
>> add extra code during the link.
>
> Perhaps a st
On Wed, Sep 22, 2010, Dave Martin wrote:
> This tells the compiler to generate PIC code, but it doesn't tell the
> linker to generate PIC output... which matters if the linker needs to
> add extra code during the link.
Perhaps a stupid question, but why -fPIC/-shared and not -fPIE/-pie?
--
Loïc
Hi,
On Wed, Sep 22, 2010 at 11:48 AM, Wolfgang Denk wrote:
[...]
>> Because U-Boot doesn't build PIC for ARM (I notice it does for some
>> other arches).
> You are referring to old code. John explitly mentioned that he was
> working on the "next" branch, which has this:
>
> # needed for
Hey
On Mon, Sep 20, 2010, Wolfgang Denk wrote:
> Is the specific tool chain in question available somewhere for
> testing?
Sure thing; the Linaro toolchain is available in source form from:
https://launchpad.net/linaro-toolchain
more specifically the GCC branch:
https://launchpad.net/
Dear Dave Martin,
In message you
wrote:
>
> >> non-interworking branch. ld has no way the veneer needs to be PIC and
> >> use the GOT, so it isn't and doesn't.
> >
> > Stupid question: why not?
>
> Because U-Boot doesn't build PIC for ARM (I notice it does for some
> other arches).
You are ref
On Tue, Sep 21, 2010 at 9:29 PM, Wolfgang Denk wrote:
> Dear Dave Martin,
>
> In message you
> wrote:
>>
>> I believe such calls are getting resolved via a veneer because of a
>> combination the thumb2-ness of libgcc and the toolchain being used.
>>
>> In principle, the linker can know that it i
On Wed, Sep 22, 2010 at 1:42 AM, Nicolas Pitre wrote:
[...]
> If you want the exact same toolchain, you may have a look at:
> http://lists.linaro.org/pipermail/linaro-toolchain/2010-September/000155.html
I don't know exactly when --use-blx was introduced, but it has
apparently existed for a lon
On Tue, 21 Sep 2010, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > Is the specific tool chain in question available somewhere
> > > for testing?
> >
> > As far as I know, any reasonably recent toolchain (e.g. like toolchains
> > released even 2
Dear Nicolas Pitre,
In message you wrote:
>
> > Is the specific tool chain in question available somewhere
> > for testing?
>
> As far as I know, any reasonably recent toolchain (e.g. like toolchains
> released even 2 years ago) will emit veneers when required.
Thanks. But that
On Tue, 21 Sep 2010, Wolfgang Denk wrote:
> Is there any information available about relative code sizes /
> performance numbers of "--emit-relocs" versus "--use-blx"?
The blx instruction will always win on both counts: it is smaller and
faster than a veneer.
> BTW: why does nobody answer my qu
Dear Dave Martin,
In message you
wrote:
>
> I believe such calls are getting resolved via a veneer because of a
> combination the thumb2-ness of libgcc and the toolchain being used.
>
> In principle, the linker can know that it is linking for >= ARMv5T due
> to the way it was configured and the
Hi,
John Rigby wrote:
> 288: e59f0148 ldr r0, [pc, #328] ; 3d8
> 28c: e1a01083 lsl r1, r3, #1
> 290: ebfe bl 0 <__aeabi_idiv>
> 294: e2507006 subs r7, r0, #6
> 298: 4a01 bmi 2a4
I believe such calls are getting reso
Dear John Rigby,
In message you
wrote:
>
> The part that does not work is that some veneer routines do not get fixed up.
These veneer routines seem to be specific to some (pretty recent?)
tool chain versions. We haven't seen any of these with older tool
chains (say, up to and including gcc 4.2.
While trying out the u-boot-next branch I found a problem. First some
explanation. On most platforms, u-boot is linked to the address it
will first start running. For example when using NOR flash U-Boot
will be linked to an address in flash. Very early in the boot
process, U-Boot copies itself
16 matches
Mail list logo
