Re: Branding for Linaro GDB package

[Ulrich Weigand]

Michael Hope  wrote on 09/21/2010 11:44:14 PM:

> > As a related question, the generated files in a standard GDB 7.2
release
> > seem to have been built on a relatively old system (RHEL 4 ?), which is
> > visible through the versions of tools like bison, flex, texinfo, and
> > gettext used to build those files.   When building our Linaro GDB
release
> > tarballs, should we:
> > - just use the tools as installed on a recent build system (say, Ubuntu
> > Lucid), or
> > - attempt to rebuild the release with the exact same set of tools used
for
> > the GDB 7.2 release?
>
> We should use the tools that come with Lucid.  This does cause a
> bigger diff but is easier to reproduce and less of a maintenance
> problem.

OK, sounds good.  We'll need to make sure to test the final released
tarball, to verify that there's no problem with those versions of
generated files ...

> I'm not happy with generated files being checked in, but we have to do
> that to be  drop-in replacement for the upstream GDB.
>
> If it's straight forward then I'd like to avoid checking in the
> generated files if the change is only due to tool changes.  We will
> regenerate everything as part of the release process but it would be
> nice to keep the branch clean.

They'll not be checked into the branch; they'll be generated on the
fly and simply become part of the tarballs.



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Dave Martin]

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 long time; the vast majority of arm-*eabi
toolchains should support it.

I guess we could have a configure-time test to see whether the option
is supported, or only use it for thumb-2 capable platforms (the latter
option may be the more sensible one, and will not cruft-ify the build
system)

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: OpenOCD

[Wookey]

+++ Zach Welch [2010-09-21 16:47 -0700]:
> On 09/21/2010 12:52 PM, Christian Robottom Reis wrote:
> [snip]

> I can
> let you know when I get my hands on some hardware to use for testing, or
> others can take a stab at it with their own boards (see below). That
> will probably take some experience with OpenOCD to be successful.

I've done a certain amount of OpenOCD poking to get it working for
CPLD programming last year, so have a reasonable idea how to drive and
configure it. But I only have a beagleboardMX to experiment on which I
imagine is one of the few things we're interested in that's already
done. 

I have plenty to do anyway right now, but could be persuaded to do
some OpenOCD testing at some point (unless someone else is particularly
keen :-). 

> > - Is there an OpenOCD starter doc we can give people that want to
> >   try OpenOCD out on their platforms (and report bugs to help
> >   provide items for your work queue)?
> 
> OpenOCD includes documentation written in TexInfo, so HTML and PDF
> versions of the current OpenOCD User Manual can be generated by running
> 'make docs' in the source tree. If that document has any shortcomings,
> they deserve to be brought up on the OpenOCD mailing list.

I found they were pretty good, especially after Mr Brownell tidied up
a lot of stuff. It does take a little while to get your head round how
it all fits together and whatever you do JTAG is always cranky in my
experience with tedious wrinkles about different dongles, interface
boards and strange effects of other devices if, for example, the JTAG
pins on the CPLD get re-used.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Dave Martin]

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 is linking for >= ARMv5T due
>> to the way it was configured and the way the input objects were built,
>> but GNU ld is conservative and doesn't do this automatically.  As a
>> result, it has to generate a veneer, reached via a normal
>> 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).

u-boot$ grep -irl -- '-fpic\|-shared' `find . -name Makefile\* -o -name \*.mk`
./arch/mips/config.mk
./arch/sparc/cpu/leon2/config.mk
./arch/sparc/cpu/leon3/config.mk
./arch/powerpc/cpu/mpc85xx/config.mk
./arch/powerpc/cpu/mpc5xxx/config.mk
./arch/powerpc/cpu/mpc824x/config.mk
./arch/powerpc/cpu/mpc86xx/config.mk
./arch/powerpc/cpu/mpc83xx/config.mk
./arch/powerpc/cpu/mpc8xx/config.mk
./arch/powerpc/cpu/mpc8260/config.mk
./arch/powerpc/cpu/mpc8220/config.mk
./arch/powerpc/cpu/ppc4xx/config.mk
./arch/powerpc/cpu/74xx_7xx/config.mk
./arch/powerpc/cpu/mpc5xx/config.mk
./arch/powerpc/cpu/mpc512x/config.mk
./arch/avr32/config.mk
./arch/m68k/cpu/mcf5227x/config.mk
./arch/m68k/cpu/mcf547x_8x/config.mk
./arch/m68k/cpu/mcf532x/config.mk
./arch/m68k/cpu/mcf523x/config.mk
./arch/m68k/cpu/mcf5445x/config.mk

Note that ARM code is fairly PIC even without -fPIC, except for
references to data (which are usually absolute), and certain cases of
veneers/trampolines inserted by the linker (as we saw).

One think I'm confused about: why do references to read-only data not
cause a problem?  I would expect the read-only data to need to be
relocated along with .text, but currently u-boot.bin references these
with absolute addresses (because of no -fPIC).  Are we just tending to
get lucky, i.e., in practice U-Boot is usually run at the link address
and copied elsewhere?

To illustrate, here's an example: note the absense of a GOT or any
relocations in u-boot, and the non-relocatable absolute reference to a
string in .rodata.str1.1

u-boot$ objdump -dr net/net.o
[...]
09d4 :
 ab8:   0079.word   0x0079
ab8: R_ARM_ABS32.rodata.str1.1
[...]

u-boot$ objdump -dh u-boot

u-boot: file format elf32-littlearm

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 00014c4c  0600  0600  8000  2**5
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata   0fdc  06014c4c  06014c4c  0001cc4c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .rodata.str1.1 4180  06015c28  06015c28  0001dc28  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data 0914  06019da8  06019da8  00021da8  2**2
  CONTENTS, ALLOC, LOAD, DATA
  4 .u_boot_cmd   0378  0601a6bc  0601a6bc  000226bc  2**2
  CONTENTS, ALLOC, LOAD, DATA
  5 .bss  00035f30  0601aa34  0601aa34  00022a34  2**2
  ALLOC
  6 .ARM.attributes 002d      00022a34  2**0
  CONTENTS, READONLY
  7 .comment  0041      00022a61  2**0
  CONTENTS, READONLY
  8 .debug_line   5dd0      00022aa2  2**0
  CONTENTS, READONLY, DEBUGGING
  9 .debug_info   0001756a      00028872  2**0
  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 6726      0003fddc  2**0
  CONTENTS, READONLY, DEBUGGING
 11 .debug_aranges 06a0      00046508  2**3
  CONTENTS, READONLY, DEBUGGING
 12 .debug_locf178      00046ba8  2**0
  CONTENTS, READONLY, DEBUGGING
 13 .debug_pubnames 22f6      00055d20  2**0
  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 0880      00058016  2**0
  CONTENTS, READONLY, DEBUGGING
 15 .debug_str4cd5      00058896  2**0
  CONTENTS, READONLY, DEBUGGING
 16 .debug_frame  3178      0005d56c  2**2
  CONTENTS, READONLY, DEBUGGING
[...]
06001a44 :
[...]
 6001b28:   06016065.word   0x06016065
[...]



As to why the linker doesn't automatically know that the expensive
veneers aren't needed, I don't think there's any really good reason;
it's just not implemented AFAIK.

ld doesn't know the target architecture in the same way that gcc does
--- I believe ld doesn't understand a -march= switch for most
architectures.

ld could guess the target architecture based on information the
compiler puts in the objects, but this might be a future thi

Re: Branding for Linaro GDB package

[Andrew Stubbs]

On 21/09/10 22:44, Michael Hope wrote:
>> GNU gdb (Linaro GDB) 7.2-2010.10-0
>> >  Copyright (C) 2010 Free Software Foundation, Inc.
>> >  License GPLv3+: GNU GPL version 3 or later
>> >  
>> >  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 "i686-pc-linux-gnu".
>> >  For bug reporting instructions, please see:
>> >  .
>> >
>> >  Do you agree that this is the way we should go?  Have I overlooked
>> >  anything?
> These all sound good.  Andrew, are there any other changes you can think of?

GDB seems fine, except that I'd prefer that it didn't say "2010.10-0" 
until we actually spin the release. GCC is currently set to "development 
2010.09-2", even though there probably never will be such a release. 
Basically, if somebody takes a snapshot, I'd like the --version string 
to be different from the official release.

What does gdbserver say?

Andrew

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Wolfgang Denk]

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 referring to old code. John explitly mentioned that he was
working on the "next" branch, which has this:

# needed for relocation
PLATFORM_RELFLAGS += -fPIC

Note that BEFORE commit f1d2b31 ("ARM: add relocation support") we
did not see such issues (at least I never did, and my underwstanding
is that John didn't either).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Time is fluid ... like a river with currents, eddies, backwash.
-- Spock, "The City on the Edge of Forever", stardate 3134.0

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: NEON vectorization improvements - preliminary notes

[Ira Rosen]

Hi Julian,

Here are some thoughts about your report.


> Automatic vector size selection/mixed-size vectors
> ==

I think we (I) need to cooperate with Richard Guenther: ask him about
committing his patch to 4.6 (they are probably planning to merge vect256
into 4.7?), offer help, etc. Looks like the last patch was committed to
vect256 in May... What do you think?

I can try to apply his patch and see how it behaves on ARM, once I have
access to an ARM board.


> Unimplemented GCC vector pattern names
> ==

> movmisalign
> -
>
> Implemented by: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00214.html

Are you waiting for approval from ARM maintainers?
Can I help somehow?
I think this patch is very important. Without it only aligned accesses can
be vectorized.

> vec_extract_even
(and interleave)
> 

We can add, as a quick solution, those VZIP and VUZIP mappings. However, in
the long term, I think we need to exploit NEON's strided loads and stores.


> sdot_prod, udot_prod
> --

dot_prod (va, vb, acc) = { va.V0 * vb.V0 + acc.V0,  va.V1 * vb.V1 +
acc.V1, ... }
meaning it's a multiply-add, where acc and result are of twice of the
length of va and vb.
And yes, it is kind of several parallel dot-product operations, as you
wrote. In the end of a vector loop we have a vector of partial results,
which we have to reduce to a scalar result in a reduction epilogue.



> ssum_widen3, usum_widen3
> 
>
> Implemented, but called widen_[us]sum3. Doc or code bug? (Doc, I
think.)

This is how it is mapped in genopinit.c:

  "set_optab_handler (ssum_widen_optab, $A, CODE_FOR_$(widen_ssum$I$a3$))",
  "set_optab_handler (usum_widen_optab, $A, CODE_FOR_$(widen_usum$I$a3$))",

So, it is implemented.


> vec_pack_trunc_
> -
>
> Not implemented. ARM have a patch:

This is implemented in neon.md.


> vec_pack_ssat_, vec_pack_usat_
> --
>
> Not implemented (probably easy). VQMOVN. (VQMOVUN wouldn't be needed).


The only target that implements that is mips, so I am not sure it is
used/needed.



> vec_widen_[us]mult_{hi,lo}_
> --

This is used for widening multiplication:

int a[N];
short b[N], c[N];

for i
 a[i] = b[i] * c[i]


which gets vectorized as following:

vector int v0, v1;
for i

  v0 = vec_widen_smult_hi (b[8i:8i+7], c[8i:8i+7]);
  v1 = vec_widen_smult_lo (b[8i:8i+7], c[8i:8i+7]);
  c[8i:8i+3] = v0;
  c[8i+4:8i+7] = v1;


I think, on NEON we can just use VMULL (and one store) to do this. But, of
course, it requires support on the vectorizer side, including probably
multiple vector size support, unless it can be abstracted out somehow...

(After writing that, I checked neon.md ;), and these two are actually
there, implemented with two instructions each  (if I read it correctly). So
with the current implementation we need 6 instructions instead of,
hopefully, only 2).



> vec_unpack[su]_{hi,lo}_
> -
>
> Not implemented. (Do ARM have a patch for this one?)

I see them in neon.md.


> NEON capabilities not covered by the vectorizer
> ===

I would start from a typical benchmark and see what features are required.


> The goal is a 15% speed improvement in EEMBC relative to FSF GCC 4.5.0
Does this mean to improve a single benchmark from EEMBC by 15%?
Do you have an EEMBC? I have a very old version, without DENBench, which
looks interesting according to EEMBC's site. Other than that TeleBench and
Consumer might have vectorization potential.


We have holidays till October 3, so probably I will not be able to respond
until then.

Thanks,
Ira


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: OpenOCD

[Christian Robottom Reis]

On Mon, Sep 20, 2010 at 11:39:15AM -0700, Zach Welch wrote:
> Specifically, I will be adding new support for Cortex-A9 SMP, though I
> may also make a few improvements to its handling of Cortex-A8 in the
> process.  If you have experience using OpenOCD in these contexts, let me
> know if you have any specific requests for features or fixes, and I will
> try to fold them into my plans.

Hello Zach,

Welcome on. We discussed OpenOCD at the last TSC meeting we had, and
we have discovered that we don't have a very firm grasp of the gaps in
OpenOCD for v7 hardware at the moment. So let me ask a few basic
questions and see if that can guide us somewhere:

- Of the platforms OMAP3, OMAP4, mx51 and U8500, does any have
  OpenOCD support today?

- Are there levels of "support" that OpenOCD can provide for a
  platform? I.e. is it all or nothing, or is there basic support and
  what's a step up from that?

- How much of OpenOCD is board-specific? In other words, does
  specific OpenOCD code (or config) need to be written to support,
  say, the Beagle versus the Beagle XM versus the IGEPv2?

- Is there an OpenOCD starter doc we can give people that want to
  try OpenOCD out on their platforms (and report bugs to help
  provide items for your work queue)?

Thanks,
-- 
Christian Robottom Reis   | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Branding for Linaro GDB package

[Ulrich Weigand]

Andrew Stubbs  wrote:

> GDB seems fine, except that I'd prefer that it didn't say "2010.10-0"
> until we actually spin the release. GCC is currently set to "development
> 2010.09-2", even though there probably never will be such a release.
> Basically, if somebody takes a snapshot, I'd like the --version string
> to be different from the official release.

Agreed.  I was showing how the output of the release build would look like.

In the Bazaar repository, I was planning to set the version string to
   7.2-2010.10-0-bzr
which is similar to what upstream does, except we use -cvs instead of -bzr,
and there's a daily date stamp -- but I don't really think we need that for
Linaro.

> What does gdbserver say?

The same:

  GNU gdbserver (Linaro GDB) 7.2-2010.10-0
  Copyright (C) 2010 Free Software Foundation, Inc.
  gdbserver is free software, covered by the GNU General Public License.
  This gdbserver was configured as "i686-pc-linux-gnu"



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Loïc Minier]

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/gcc-linaro
 (there are tarball downloads or you can check it out with bzr)

 There are some pre-built packages for the development series of Ubuntu
 ("maverick"), "apt-get install gcc-arm-linux-gnueabi" should do the
 trick.  There aren't any other pre-built binaries available yet though
 (well there are some Debian armhf one, but don't think you care about
 these).  If you're running Ubuntu 10.04 ("lucid"), these instructions
 allow installing the maverick packages:
 https://wiki.linaro.org/MichaelHope/Sandbox/CrossCompilerOnLucid

 NB: the Ubuntu binaries are built for eglibc (linux-gnu-eabi), i.e. not
 no-libc.
-- 
Loïc Minier

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Dave Martin]

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 relocation
>        PLATFORM_RELFLAGS += -fPIC

Ah!  Apologies, I missed that...  looks like I'm out of date on some
assumptions.

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.

Two solutions come to mind:

a) In order for linker-added stuff to be PIC, you could link with
-shared.  This will definitely PIC-ify any veneers added by the linker
and push related relocations into the GOT.  Strictly speaking it might
be wrong not to do this if you expect the output from the linker to be
fully PIC -- if so, this may apply to all arches where the linker may
generate code.  Naturally, it's necessary to ensure that the U-Boot
ELF image doesn't accidentally get linked against any shared libs.
Checking for DT_NEEDED entries in the u-boot ELF image would be a way
to sanity-check this, but the way the U-Boot drives the link looks
pretty safe (no -l options; explicit references to .a libs only etc.)

b) For ARM specifically, there is also a --pic-veneer option which may
also Do The Right Thing in the specific case of these veneers, even
when not using ld -shared.  Again, I don't know precisely which
toolchain versions support this; if we want to be really safe it may
be necessary to probe for support for this option at configure-time.

--use-blx is probably still a good idea in either case, but this is
more about optimisation than correctness.  The optimisation is
probably still worthwhile though, if it might speed up calls into
libgcc.

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Loïc Minier]

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 Minier

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Dave Martin]

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 stupid question, but why -fPIC/-shared and not -fPIE/-pie?

Dunno :)

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 / -pie / (nothing) probably just changes
which linker script is used by default.  U-Boot overrides the default
with its own linker script anyway, so it may make no difference.

---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Loïc Minier]

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 / -pie / (nothing) probably just changes
> which linker script is used by default.  U-Boot overrides the default
> with its own linker script anyway, so it may make no difference.

 Catching up on email, I just came across:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84789
 so it seems to be different, but not significantly

 I don't care too strongly, but it might make sense to try to use the
 flag which means exactly what we want to allow for future
 optimizations?

-- 
Loïc Minier

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: arm thumb veneer question

[Dave Martin]

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 PIC veneers (as for -shared).  Beyond
>> this, I think ld -shared / -pie / (nothing) probably just changes
>> which linker script is used by default.  U-Boot overrides the default
>> with its own linker script anyway, so it may make no difference.
>
>  Catching up on email, I just came across:
>    http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84789
>  so it seems to be different, but not significantly

Hmmm, interesting discussion: looks like my guess was naive ;)

It looks like -fPIE provides some savings after all, since it enables
the compiler to make some additional assumptions.

>  I don't care too strongly, but it might make sense to try to use the
>  flag which means exactly what we want to allow for future
>  optimizations?

Since U-Boot is now trying to build PIC anyway, I suggest that for
things to work robustly one of the following is needed anyway:

  * -fPIE + -pie
  * -fPIC + -shared (less optimal?)

Logically, pie seems to be the closest match to what is actually
happening in U-Boot.

Then we can optionally add:

  * --use-blx (to get rid of ARM<->Thumb interworking veneers)

--pic-veneers could be used as a temporary fix, but this feels fragile
to me: it only controls a speicific aspect of linker behaviour, so we
could hit other problems in the future.  We could do this as a
short-term workaround to allow the linaro toolchain to be used in the
meantime, though.

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Host strip corrupts cross-built binaries

[Loïc Minier]

Hi folks

 apparently some tool calls "strip" instead of "$triplet-strip" when
 cross-building; this is something we shall fix, but it is apparently
 corrupting the binaries in some cases:
 https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/615765

 It seems the ELF architecture isn't set properly, or so I'm told.

 Which component is to blame here?  Are we looking at a binutils or a
 gcc bug for not being able to set or read enough data that the
 architecture mismatch isn't detected?  What could we do about it?

   Thanks!
-- 
Loïc Minier

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Host strip corrupts cross-built binaries

[Mark Mitchell]

On 9/22/2010 8:34 AM, Loïc Minier wrote:

>  Which component is to blame here?  Are we looking at a binutils or a
>  gcc bug for not being able to set or read enough data that the
>  architecture mismatch isn't detected?  What could we do about it?

This is definitely a binutils bug.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: NEON vectorization improvements - preliminary notes

[Andrew Stubbs]

On 22/09/10 12:23, Ira Rosen wrote:
>> The goal is a 15% speed improvement in EEMBC relative to FSF GCC 4.5.0
> Does this mean to improve a single benchmark from EEMBC by 15%?
> Do you have an EEMBC? I have a very old version, without DENBench, which
> looks interesting according to EEMBC's site. Other than that TeleBench and
> Consumer might have vectorization potential.

I don't think this is well defined, so, I guess that means we get to 
twist it any way we like. ;)

Seriously though, I would argue that it should be 15% on average, across 
all the EEMBC tests, or at least across all the tests where 
vectorization makes sense.

The exact "15%" figure is not based on any hard facts, so we don't need 
to get too precise about it.

Andrew

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Linaro GDB release process

[Ulrich Weigand]

Hello,

I've now checked the Linaro branding changes in to the gdb-linaro Bazaar
repository.

I've created a Wiki page describing the Linaro GDB release process based on
that repository:
http://wiki.linaro.org/WorkingGroups/ToolChain/GDBReleaseProcess

(modeled after Andrew's GCCReleaseProcess page)

Review and comments are welcome!


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain