RM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247:
> > Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > make[2]: *** [arch/arm/lib/copy_from_user.o] Error 1
> > make[1
ikely scenario, but I wanted to bring it up in case the plan
would prevent this and could easily be made not to.)
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Fri, Mar 16, 2012, Michael Hope wrote:
> https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Is there a separate plan for gcc-4.5 deprecation in source releases?
The triplet situation is sad; is there any hope that we fix this
upstream?
--
Loïc Min
e u-boot build, it's reliable?
If not, can I check the architecture for which libgcc was built
programatically?
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
the
resulting u-boot ELF binary at the end of the build? If I read you
correctly, you seem to suggest that it would be too fragile?
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Mv5 (virtual) board. (It wasn't easy to spot that the problem came
from libgcc.)
If there was a way to fail the build when ARMv5 is requested but only
ARMv7 is available that'd be ideal.
(Indeed, Ubuntu prepackaged Linaro-based cross-toolchains don't offer
multili
rch/arm/lib/eabi_compat.o -L
/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -lgcc -Wl,-Map u-boot.map -o u-boot
But this command works and produces an u-boot ELF which has
Tag_CPU_name: "7-A".
How would I break the build when libgcc isn't ARMv5T?
Thanks,
--
Loïc Minier
__
ng or not.
>
> Get it here: http://people.linaro.org/~hrw/generic-linux/ (64bit only)
This is awesome news; thanks a lot for working on this!
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro
On Fri, Jul 29, 2011, Loïc Minier wrote:
> How does that actually work to select the runtime linker? I was
> looking into setting the --dynamic-linker from -mfloat-abi=* flags, but
> didn't manage to. Apparently, this is getting resolved for gcc 4.7,
> but I was curious how yo
r softfp and hard float-abi.
How does that actually work to select the runtime linker? I was
looking into setting the --dynamic-linker from -mfloat-abi=* flags, but
didn't manage to. Apparently, this is getting resolved for gcc 4.7,
but I was curious how you dealt with this for gcc
ng testing."
[...]
"Thanks to Peter Maydell at Linaro and ARM with his hard work to make
this happen (first in upstream, and now on Android)."
[...]
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http:/
I stripped two attachments as these were too large; these are at:
http://people.linaro.org/~lool/usbmsd.objdump-SourceryG++Lite-2011.03-41
http://people.linaro.org/~lool/usbmsd.objdump-linaro-2011.03
Cheers
--
Loïc Minier
___
linaro-toolchain
Hey
I've let this one through, but in the future would you please gzip your
attachments so that they are smaller than 100 KiB total, or host them
somewhere?
Thanks!
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-tool
On Mon, Apr 11, 2011, Ramana Radhakrishnan wrote:
> I was going to kick off an FSF 4.5 testrun this week for a couple
> of my other backports so I can run that through the test run and
> submit it upstream.
Would be awesome, thanks!
--
Lo
n/gcc/current/SOURCES/gcc_pr44768.patch
(Thanks to Arnaud Patard for the above links!)
I think it's r99440 in gcc-linaro.
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listi
.s -A5 | grep return
this seems to be due to the combination of tryexec being static, its
parent being noreturn, and one argument of tryexec being unused.
Any idea of which Linaro patch solved this? :-)
Does it make sense to raise this to FSF GCC 4.5?
Tha
target
the latest LTS release of Ubuntu as a possible base rather than all
LTSes; for instance, we try to provide backports to Ubuntu 10.04 but
not to Ubuntu 8.04 or Ubuntu 6.06.
Thanks!
--
Loïc Minier
___
linaro-toolchain mailing lis
Hey
I'm trying to extend the *link: specs to pass a different
-dynamic-linker depending on the float ABI. But I didn't manage to
build a construct which would preserve the order of the flags; if I do
something like:
%{msoft-float:-dynamic-linker V1} %{mfloat-abi=softfp:-dynamic-li
r Android support
efforts:
https://wiki.linaro.org/AndroidResources
there is one kernel git tree for all boards and the Android downloads
tab on arm.com/linux has some binaries; the linux-arm.org wiki has some
instructions.
Cheers
--
Loïc Minier
_
y people would be interested in
this, but I'm not sure what kind of support situation we'd put
ourselves in by publishing these.
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org
ole=ttyAMA0,115200 and console=ttyAMA0,38400n8
to no luck.
u-boot-linaro doesn't start in QEMU either.
Would you have some test kernel and instructions?
It seems PCI is working for you, which is really nice! Any issue with
the tree?
BTW are these patches being sent ups
rs
of maverick and you wont have to build it yourself :-)
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
verified to work
On Wed, Jan 19, 2011, Nicolas Pitre wrote:
> On Wed, 19 Jan 2011, Loïc Minier wrote:
>
> > Hey
> >
> > I think we need to keep an eye on this and be ready to check ltrace if
> > this gets merged
>
> I think ltrace is broken alre
Hey
I think we need to keep an eye on this and be ready to check ltrace if
this gets merged
Cheers
--
Loïc Minier
--- Begin Message ---
Hi Russell,
> On Wed, Jan 19, 2011 at 03:07:15PM +, Will Deacon wrote:
> > I'm posting this as an RFC to see if anybody has a
xpectations and the Linaro changes and we need to discuss a good
path forward so that these patches can be included upstream. Exactly
as this would be discovered/discussed upstream :-)
We can meet in Dallas in ~20 days and discuss this face to face as well
:)
--
Loïc Minier
__
ian/
should work
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
too large patch, I don't
think there is interest in spending too much time in fixing 4.4 bugs
when the focus moved to 4.5. We should put our efforts in providing
backports, and that will make everybody happier :)
--
Loïc Minier
___
linaro-toolchain
sition to request inclusion; it's a bit chicken and egg, so we could
just inform them that we're starting a prototype with this and that
number and then circle back when it's done?
--
Loïc Minier
___
linaro-toolchain maili
:-)
would it be good if we kept working with bzr, but we pushed to svn (via
bzr-svn) nightly? Whenever some non-Linaro person sends a patch
against SVN, it should apply equally well on top of bzr
--
Loïc Minier
___
linaro-toolchain mailing li
arties
I don't have the list, but I remember Andrew mentioning this for some
of the useful patches we merged
(there was also a debate on the risk of contamining code we'd like to
upstream with this non-assigneable code, so maybe we reverted these)
quot;submit a presentation" sense here?
Maybe you could give a lightning talk on the validation work you've
started doing? :-)
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
e and access the data in their preferred
format and we can keep existing practices
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
bably want to --enable-neon and --cpu=cortex-a8 too.
Cheers,
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Wed, Oct 13, 2010, Nicolas Pitre wrote:
> http://gcc.gnu.org/bugzilla/show_bg.cgi?id=45979
(missing "u")
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45979
--
Loïc Minier
___
linaro-toolchain mailing list
lin
ccidental that libgcc built for -march=armv7 works on
older CPUs? Why can't this mechanism be extended to -marm/-mthumb and
to VFP options?
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
actual issue here? U-Boot is built with -marm; does
it cause any issue to mix with our Thumb-2 libgcc?
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Tue, Oct 05, 2010, Zach Welch wrote:
> Personally, I think the simplest/best solution will be to encourage
> upstream to release a new version.
Fully agreed! (I think we're only having this conversation because of
the feedback that upstream didn't seem to be around anymore)
version trick above
Note however that you don't really know whether the next ltrace will
have the patch or not, or a different patch. It's also hard to make
sure you don't supersede an upstream version you didn't intend to
supersede, or vice-versa: upstream could pick any
his one, or valgrind or qemu or simply the
toolchain
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
there's not, it's also a binutils bug :-)
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Wed, Sep 22, 2010, Loïc Minier wrote:
> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/615765
This is important to the Foundation team; would someone have time to
look into this?
Thanks!
--
Loïc Minier
___
linaro-toolchain mail
w TODO entries in it, though...)
Good notes on the valgrind release process; close to what I used to do
at least
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
F 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 ab
p.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
_
not -fPIE/-pie?
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
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
n choose the best one based on the
> chip it is running on.
Actually I understand STT_GNU_IFUNC would allow that, we just lack a
good test
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/m
ould be to add some glibc config to
turn on or off usage of NEON, or have glibc read cpuinfo or something
to identify the CPU model and manufacturer.
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
t it's more work
than a manually rolled toolchain
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Wed, Sep 08, 2010, Michael Hope wrote:
> See http://ex.seabright.co.nz/helpers/benchcompare for more.
at /helpers/benchcompare
values is an empty list when calling square() in
templates/benchcompare.html; the web backtrace seems off by some lines
for some reason
--
Loïc Min
bl 0x1c44
0x1c48 <+44>: mov r1, r4
0x1c4a <+46>: ldmia.w sp!, {r4, r5, r6, r7, r8, lr}
0x1c4e <+50>: b.w 0x1c4e
0x1c52 <+54>: ldmia.w sp!, {r4, r5, r6, r7, r8, pc}
0x1c56 <+58>: nop
0x1c58 <+60>: andeq r0, r
On Fri, Sep 03, 2010, Marcin Juszkiewicz wrote:
> Today I got a-c-t-base to a moment when it builds fine on PPA
Awesome! Well done
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mail
t always
trivial to build it in Thumb mode, but it would seem like a good test
case nevertheless. At least if it builds, looking at the resulting
size would be a good test, even if it doesn't boot :-)
--
Loïc Minier
___
linaro-toolchain mailing
ny case.
>
> See
>
> http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-default-ssp.diff
> for how Debian does this.
How can we fix this in the upstream sources? Should glibc or libgcc
detect this erroneous state?
--
Loïc Minier
__
On Tue, Aug 17, 2010, Michael Hope wrote:
> Thoughts?
Looks good!
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Hi
I'm concerned that the workaround for apr was just uploaded in the form
of disabling process shared mutexes (see LP #599874), but we didn't
address or investigate the root cause in eglibc.
Would someone be able to look at LP #604753 where the issue is tracked?
Thanks
Just out of date, good catch
Would you mind updating that? Or even better, pointing at
lists.linaro.org which is always up-to-date
Thanks!
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org
s can
follow the link
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
t; 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
--
Loïc Minier
___
linaro-toolchain ma
replace
/lib/ld* with a clever wrapper that calls the proper
/lib/$(multiarch)/ld.so.1 depending on the architecture of the ELF file
to load.
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
s your point that we should disable the qemu loader for the native
architecture? I certainly agree we need to!
> Yes, that's during compile time. I understand the reason for this is more
> to catch bad include paths manually specified in packages. Not sure if
&g
g. x86 to ARM), consider
cross-builds from x86-64 to x86, or from EABI + hard-float to EABI +
soft-float.
BTW, the CodeSourcery patchset contains a "directory poisoning" feature
which seems quite useful to detect these cases early.
Thanks again for your writeup!
--
Loïc Minier
_
le have IGEPs now, it would be nice
to help them get started.
I had put Julian's instruction at
https://wiki.linaro.org/Boards/Igep
perhaps you can extend that proposing an alternate install?
--
Loïc Minier
___
linaro-toolchain mailing lis
in a
regular build.
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
e a slightly different .dsc, albeit with approaching
contents. ]
Cheers,
--
Loïc Minier
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Tue, Jul 27, 2010, Michael Hope wrote:
> * Loic talked with a developer on Chrome OS
> * ACTION: Loic to find a name for the records
Olof Johansson, "ojn" on freenode -- but I don't think he is
particularly specialized in toolchain stuff, just a ChromeOS dev I
ch
66 matches
Mail list logo
