Re: Armhf dynamic linker path
On 04/09/2012 10:19 PM, Mike Frysinger wrote: On Monday 09 April 2012 15:47:56 Adam Conrad wrote: are you not just as much hindering Debian over nothing more than a path to a single file? nope. sounds more like self inflicted pain. To be very, very, very clea here. multilib can not solve the "different base arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as soon as you have more than one of x86, arm, power, mips, etc. no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem". Don't the multilib paths contain enough information to handle this? They certainly have in the past as I can recall building toolchains that handled several architectures within power, arm & mips families in the past Is the problem here that glibc simply isn't building multilib paths in the same way that GCC has for the last 15 years? jeff ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On 04/09/2012 10:33 PM, Mike Frysinger wrote: his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions. Hmmm, why would anyone want to install distinct architectures in the same root... I must admit I don't recall that being discussed at Plumbers. Jeff ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On 04/10/2012 04:42 AM, Steve McIntyre wrote: It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages. > See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale. I've read it and still don't see the benefit, particularly as it relates to mixed instruction sets. Or more precisely, I don't see the value in supporting mixed instruction sets. Once you drop the mixed instruction set argument I think the whole argument for embedding the target triplet into the dynamic linker pathname falls apart. We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location. But the entire reason behind the need to embed the triplet into the dynamic linker's path is the debian multi-arch stuff AFAICT. I think that's what many folks are complaining about. I realize the goal here is to allow a single binary to run on multiple systems and I think that's a worthy goal. Jeff ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.
On 9/27/2021 7:52 AM, Aldy Hernandez wrote: [CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please take a look if this is something that could be easily fixed? First of all, thanks for chasing this down. It's incredibly useful to have these types of bug reports. Jeff and I have been discussing the repercussions of adjusting the loop crossing restrictions in the various threaders. He's seen some regressions in embedded targets when disallowing certain corner cases of loop crossing threads causes all sorts of grief. Out of curiosity, does the attached (untested) patch fix the regression? And just a note, that patch doesn't seem to fix the regressions on visium or rl78. I haven't checked any of the other regressing targets yet. jeff ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
