On Mon, Aug 02, 2010, Wookey wrote:
> > https://wiki.linaro.org/WorkingGroups/ToolChain/MultiarchPaths
> http://wiki.debian.org/Multiarch/Spec
> (and deleted the original so we don't get two diverging versions).
I've added a redirect so that people reading the list archives can
follow the link
Minutes from the Toolchain WG weekly meeting are available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-02
A copy, along with activity reports, follow.
-- Michael
= Monday 2nd August 2010 =
== This month's meetings ==
<>
== Attendees ==
||Name ||Email ||IRC Nick ||
+++ Ulrich Weigand [2010-08-02 16:13 +0200]:
> > We should post it on the Linaro wiki, probably.
>
> It's now on:
> https://wiki.linaro.org/WorkingGroups/ToolChain/MultiarchPaths
As this is actually a much wider issue than just Linaro, (and because
it is better presented to other interested parti
On Mon, Aug 02, 2010 at 04:31:16PM +0200, Ulrich Weigand wrote:
> Steven asked: "What do you folks think of this patch?"
> and the only answer was by Richi: "I think it's reasonable."
>
> So I'm not sure why it didn't go in. Maybe we should just ping Steven?
It's been a while, but I think discus
Ulrich Weigand wrote:
> Andrew Stubbs wrote:
>
>> Some discussion later, they decided it would be better to implement the
>> optimization using inter-procedural dead store analysis:
>>http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html
>
> I agree that this would be a much nicer way ...
On 02.08.2010 21:12, Ulrich Weigand wrote:
> Matthias Klose wrote on 08/02/2010 06:25:58 PM:
>
>> this is no "cheating". It makes the packages robust. Remember that some
>> frontends are built from different source packages and that a
>> gnat-4.4 (4.4.4) still needs to be buildable with a gnat-4.
Loïc Minier wrote:
> > If we have to install different native versions of the clever wrapper,
> > we might just as well install the original native ELF interpreters --
> > that's neither better nor worse from a multiarch rules perspective.
>
> Hmm right; doesn't give us anything more
OK, then we
Matthias Klose wrote on 08/02/2010 06:25:58 PM:
> this is no "cheating". It makes the packages robust. Remember that some
> frontends are built from different source packages and that a
> gnat-4.4 (4.4.4) still needs to be buildable with a gnat-4.4 (4.4.3)
> and an already updated gcc-4.4 (4.4.4
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> So now we get back to my original question: what file type would that
> "clever wrapper" be? The kernel can only load an ELF interpreter that is
> itself an ELF file of the native architecture, so that wrapper would
> have to be that. However, this me
Andrew Stubbs wrote on 08/02/2010 06:47:36 PM:
> On 02/08/10 16:03, Ulrich Weigand wrote:
> > Latest status seems to be that the original patch no longer applies,
> > but Joern did an updated (and somewhat modified) version. This seems
> > to have triggered a more general discussion on how to cor
On 02/08/10 16:03, Ulrich Weigand wrote:
> Latest status seems to be that the original patch no longer applies,
> but Joern did an updated (and somewhat modified) version. This seems
> to have triggered a more general discussion on how to correctly
> estimate the effect of adding PHI nodes on code
On 02.08.2010 14:00, Ulrich Weigand wrote:
> Loïc Minier wrote:
>> and I think
>> Debian/Ubuntu toolchains cheat in some areas; for some directories
>> which would use $(version) we use $(major).$(minor) instead, and we
>> have a $(version) -> $(major).$(minor) symlink. This doesn't real
Loïc Minier wrote:
> > I understood you to propose an alternative solution that would keep the
> > old ELF interpreter name (/lib/ld.so.1) embedded in executables, and
> > keep them working by installing some "common" loader at this location.
>
> Ah no, I intended us to move to /lib/$(multiarch)
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> Maybe I misunderstood something else about your point then, so let's try
> and take a step back. Today, the location of the ELF loader is embedded
> into the executable itself, using a full pathname like /lib/ld.so.1.
> In a multiarch world, this pathn
Loïc Minier wrote on 08/02/2010 05:30:05 PM:
> > > or more elegantly we could
> > > have a generic loader which checks the architecture of the target
ELF
> > > file before calling the arch-specific loader. This loader would be
> > > linked to from all the old locations.
> >
> > Well, but the
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> Agreed. Not sure what this particular divergence helps ...
So Matthias mentionned that gnat and gcc are not always using the same
minor version, and so it helps bootstrap them to have the common bits
installable without overly strict dependencies.
Daniel Jacobowitz wrote:
> On Mon, Aug 02, 2010 at 04:31:16PM +0200, Ulrich Weigand wrote:
> > Steven asked: "What do you folks think of this patch?"
> > and the only answer was by Richi: "I think it's reasonable."
> >
> > So I'm not sure why it didn't go in. Maybe we should just ping Steven?
>
>
Andrew Stubbs wrote:
> CS has this patch in SG++:
> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html
>
> This patch improves code size in a useful, target independent way, but
> was not committed upstream. It's not clear why. Since the patch does not
> belong to CodeSourcery, we can't upst
Andrew Stubbs wrote:
> Some discussion later, they decided it would be better to implement the
> optimization using inter-procedural dead store analysis:
>http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html
I agree that this would be a much nicer way ...
> This doesn't seem to have actu
CS has this patch in SG++:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html
This patch improves code size in a useful, target independent way, but
was not committed upstream. It's not clear why. Since the patch does not
belong to CodeSourcery, we can't upstream it ourselves either.
Is th
On 29/07/10 17:23, Andrew Stubbs wrote:
> So basically we're left with this patch that does something we want, but
> not in a way that can go upstream. :(
>
> The question is, should I merge this to Linaro, or not? Loic and I
> agreed to hold off until I'd done a bit more research and/or tried to
>
Andrew Stubbs wrote:
> It is buried a little deep, but it is there. I guess I'd like to see a
> flow of how a binary loads libraries:
>
> 1. User launches binary.
>
> 2. Kernel selects a suitable execution environment (native/qemu).
>
> 3. Kernel reads .interp and loads the multiarch dynamic link
On 02/08/10 12:46, Ulrich Weigand wrote:
> The second half of the section "Loading/running an executable" is about
> thw HWCAP stuff (look for "capability suffix"). In the summary I have
> this point:
>
> * If capability-optimized ISA/ABI-compatible library variants are desired,
>they can be b
Loïc Minier wrote:
> Awesome analysis!
Thanks!
> So I think you analyzed the upstream toolchain behavior
Yes, that's true.
> and I think
> Debian/Ubuntu toolchains cheat in some areas; for some directories
> which would use $(version) we use $(major).$(minor) instead, and we
> have a $(
Andrew Stubbs wrote on 08/02/2010 01:35:01 PM:
> On 31/07/10 19:01, Ulrich Weigand wrote:
> > I've finally completed a first of draft the write-up of toolchain
> > implications of multiarch paths that we discussed in Prague. Sorry it
took
> > a while, but it got a lot longer than I expected :-/
>
On 31/07/10 19:01, Ulrich Weigand wrote:
> I've finally completed a first of draft the write-up of toolchain
> implications of multiarch paths that we discussed in Prague. Sorry it took
> a while, but it got a lot longer than I expected :-/
>
> I'd appreciate any feedback and comments!
Thanks Ulr
The minutes from last Friday's standup call are at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-30
-- Michael
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolc
27 matches
Mail list logo
