[Activity] Week 13

2012-03-31 Thread Zhenqiang Chen
Summary:
* Linaro binary toolchain 2012.03 release.
* Investigate relocatable NLS support.
* Code size benchmark analysis.

Details:
1. Linaro binary toolchain 2012.03 release.
  * Bump and spawn 2012.02-20120326 build.
  * Validate the release candidate.
  * Update wiki for binary build tasks.
2. Investigate relocatable NLS support: lp:918926.
  * Root cause: gcc and binutils use a fixed LOCALEDIR (which is
$prefix/share/locale) to call bindtextdomain.
  * Workout a reference patch for gcc to use relative dir
(.../bin/../share/locale) to call bindtextdomain.
3. Code size benchmark analysis with -Os
  * Collect code size benchmark data.
  * In most cases, gcc 4.7 gets better result than gcc 4.6.
  * Investigate regression in several small cases.
4. Read the tree and rtl dump files to learn the optimizations and
impacts on code size.

Plans:
* Fix lp:918926.
* Investigate code size regression in gcc 4.7.
* Tuning optimization heuristics for -Os.

Planed leaves:
* April 2 - 4: Chinese Qingming Festival.
* April 9 - 11: Vacations

Best regards!
-Zhenqiang

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


Armhf dynamic linker path

2012-03-31 Thread Steve McIntyre
Hi folks,

We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is

 /lib/arm-linux-gnueabihf/ld-linux.so.3

but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.

This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.

I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs


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


Re: Armhf dynamic linker path

2012-03-31 Thread Dennis Gilmore
On Sat, 31 Mar 2012 11:34:13 +0100
Steve McIntyre  wrote:

> Hi folks,
> 
> We really need to push on with getting the loader path for armhf
> standardised. The path that was agreed months ago is
> 
>  /lib/arm-linux-gnueabihf/ld-linux.so.3
> 
> but clearly not everybody is using that yet. Dann has just posted an
> updated patch for gcc, and we want to get this reviewed / fixed up /
> accepted ASAP. Then we may need to backport it to older gcc releases.
> 
> This is *important* so that we can help vendors release binaries that
> work on any hard-float distribution. For people who have made binaries
> that still use the old, broken location /lib/ld-linux.so.3, we can put
> symlinks in place *for now* but in the longer term as many distros
> switch to multi-arch the symlink is not an acceptable solution.
> 
> I'm working on a more complete spec document for armhf to help us with
> this kind of thing, but it's not going as smoothly as I'd hoped and I
> don't want to wait for that as a blocker on the linker path.
> 
> Cheers,

I can say for Fedora that we have no plans to adopt that change. AFAIK
we never agreed to do so infact this is the first ive heard of it,  we
have moved everything from /bin /lib /lib64 to under /usr in Fedora 17.
we do have symlinks to the original locations.

we use a host triplet of redhat-linux-gnu everywhere, we have special
handling in gcc and glibc to set it to redhat-linux-gnueabi for those
two builds  we also set the arch portion to the target arch so it is
one of armv7hnl-redhat-linux-gnu or armv5tel-redhat-linux-gnu its done
that way to maintain compatability with all our other arches we use
armhfp as the base arch for floating point in Fedora. at this point
we support armv7hl as the base arch and armv7hnl as a sub arch for neon
optimised things though really neon iwmmx etc should all be run time
detectable. I really dont see the linker path being set as proposed as
working for us any time soon. its not to say that we cant change things
in the future. but its not been proposed or even thought of since
awareness at this point is nill.

I have no idea how linaro actually works or engages the community
because ive never seen it do so. I suggest if you really want to change
something on all distros you need to reach out and engage them. Im not
trying to inflame or otherwise start any kind of argument. Im want to
make sure we engage in a positive discussion. I really have no idea how
this was planned or where it was discussed or anything about it. If the
goal is to effect change within distros, the distros need to be fully
engaged. 

This needs to be a two way street. From my perspective there are many
things that need to be fixed to making supporting arm by distros scale
better, they are problems that need to be fixed at higher levels than
the distros.  I will work to find where to engage people to get them
worked on. 

Regards

Dennis

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


[ACTIVITY] Mar 26 - Mar 30

2012-03-31 Thread Ulrich Weigand

== GCC ==

 * Committed fix for LP #960283 (PR tree-optimization/52686) to
   FSF mainline as well as Linaro GCC 4.6 and 4.7.

 * Worked on patch to use vld1.64/vst1.64 instead of vldm/vstm
   for vector moves.  Created merge request for testing.

 * Worked on patch to use vld1/vst1 to implement vec_set/vec_extract
   for cases where the scalar operand resides in memory.
   Created merge request for testing.

 * Ongoing work on fixing LP #959242.

 * Ongoing work on improving end-of-loop value computation.


== Misc ==

 * I'll be attending the Linux Foundation Collaboration Summit
   in San Francisco next week, and present on "GDB on ARM".



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: Armhf dynamic linker path

2012-03-31 Thread Jon Masters
On 03/31/2012 10:42 AM, Dennis Gilmore wrote:

> I can say for Fedora that we have no plans to adopt that change. AFAIK
> we never agreed to do so infact this is the first ive heard of it,  we
> have moved everything from /bin /lib /lib64 to under /usr in Fedora 17.
> we do have symlinks to the original locations.

Dennis,

For context, we have discussed this several times at Linaro Connect and
other events, and I've talked it through with Jeff Law and others. What
we agreed to at the time (and in other conversations) was that following
an upstream proposal for a linker prefix change, then we'd look at it. I
know a number of baseos types on the Fedora end actually like the idea.
So, it would be unfair to say it hasn't been thought about, but it's not
been put out to FESCo, etc. because this is something that needs to fix
changed upstream before Fedora.

Jon.


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


Re: Armhf dynamic linker path

2012-03-31 Thread Jon Masters
On 03/31/2012 12:52 PM, Dennis Gilmore wrote:

> Linaro Connect and other events are probably the worst place for such
> decisions and discussions to be made.

So the purpose of discussing it there was twofold:

1). To debate what the preferred single unified path would be - it's ARM
specific, it makes sense to do it somewhere :)

2). To push back about the need for an upstream strategy. I spoke with a
number of folks on our end discretely about this, and in the interest of
not being burned, everyone said it needed to be proposed upstream before
we'd consider touching it.

At the same time, I think I'd like to apologize for any failure on my
part here. I want cross-distribution harmony and co-ordination, but we
live in a world fraught with politics and distrust between different
Linux players. So, I approach this with much caution having been burned
in the past with what seemed like reasonable ambitions. I'll go out and
buy some new asbestos pants and try a more direct approach next time.

Jon.

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


Re: Armhf dynamic linker path

2012-03-31 Thread Dennis Gilmore
On Sat, 31 Mar 2012 12:04:20 -0400
Jon Masters  wrote:

> On 03/31/2012 10:42 AM, Dennis Gilmore wrote:
> 
> > I can say for Fedora that we have no plans to adopt that change.
> > AFAIK we never agreed to do so infact this is the first ive heard
> > of it,  we have moved everything from /bin /lib /lib64 to
> > under /usr in Fedora 17. we do have symlinks to the original
> > locations.
> 
> Dennis,
> 
> For context, we have discussed this several times at Linaro Connect
> and other events, and I've talked it through with Jeff Law and
> others. What we agreed to at the time (and in other conversations)
> was that following an upstream proposal for a linker prefix change,
> then we'd look at it. I know a number of baseos types on the Fedora
> end actually like the idea. So, it would be unfair to say it hasn't
> been thought about, but it's not been put out to FESCo, etc. because
> this is something that needs to fix changed upstream before Fedora.
> 
> Jon.
> 

Linaro Connect and other events are probably the worst place for such
decisions and discussions to be made. though maybe there is not a good
place. the wider community needs to be engaged for greatest acceptance.
otherwise then if falls into the vacuum of those attending the events.
Like I said its not that it could never happen just that its not been
discussed at all. so requesting that distros adopt it is a bit harsh
and unrealistic. I guess i need to go find and read the existing
documents on what exactly is proposed and how it is intended to work.
Its not been thought about in the wider community, I suspect its not
been thought about in other distros also. I am open to being wrong. 


Dennis

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


Re: Armhf dynamic linker path

2012-03-31 Thread Jon Masters
On 03/31/2012 12:04 PM, Jon Masters wrote:
> On 03/31/2012 10:42 AM, Dennis Gilmore wrote:
> 
>> I can say for Fedora that we have no plans to adopt that change. AFAIK
>> we never agreed to do so infact this is the first ive heard of it,  we
>> have moved everything from /bin /lib /lib64 to under /usr in Fedora 17.
>> we do have symlinks to the original locations.

> For context, we have discussed this several times at Linaro Connect and
> other events, and I've talked it through with Jeff Law and others. What
> we agreed to at the time (and in other conversations) was that following
> an upstream proposal for a linker prefix change, then we'd look at it. I
> know a number of baseos types on the Fedora end actually like the idea.
> So, it would be unfair to say it hasn't been thought about, but it's not
> been put out to FESCo, etc. because this is something that needs to fix
> changed upstream before Fedora.

So they're doing the right thing here in proposing stuff upstream.
That's the long and the short of it. I suggest we allow that to happen,
and some of us who think it's a good idea can express enthusiasm for
those patches. Then, once there is an upstream solution, we can come
back to the Fedora community and suggest some changes more broadly. This
didn't happen in a vacuum (honest), but we knew that nobody in Fedora
would be interested in a non-upstream viable solution.

This is another reason why v8 will not be allowed to repeat the same
mistakes. None of us in any of the distros should adopt any v8 release
until we have agreed on the path to the frigging linker. That's just
plain crazy. I note that I was up late reading the prelink sources and
I'm also wondering (totally unrelated) how much fun that will be :)

Jon.

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