On Mon, 4 Jan 2016, Adhemerval Zanella wrote:
> Nicolas, I am about to start a new thread about ""ld -r" on mixed
> IR/non-IR objects", asking current status from H.J. Lu, what is
> preventing upstream merge, concerns and objections.
>
> First I would to know which the priority of this feature
On Wed, 23 Dec 2015, Adhemerval Zanella wrote:
>
>
> > Em 22 de dez de 2015, às 14:22, Nicolas Pitre <nicolas.pi...@linaro.org>
> > escreveu:
> >
> >> On Mon, 21 Dec 2015, Jim Wilson wrote:
> >>
> >> I tracked the bulk of the p
On Mon, 21 Dec 2015, Jim Wilson wrote:
> I tracked the bulk of the patch back to April 2011, though some new
> LTO related testsuite changes date back to January 2011. The initial
> patch submission for the bulk of the patch appears to be
>
On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
On 18-06-2015 11:26, Nicolas Pitre wrote:
On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
On Jun 17, 2015, at 3:15 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Thu, 4 Jun 2015
On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
On Jun 17, 2015, at 3:15 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Thu, 4 Jun 2015, Jim Wilson wrote:
The normal toolchain process is that patches get added to our releases
On Thu, 4 Jun 2015, Jim Wilson wrote:
The normal toolchain process is that patches get added to our releases
only if they are already upstream. Our releases are FSF releases plus
patches backported from mainline, with no local changes except when
absolutely unavoidable.
It is commit
On Thu, 4 Jun 2015, Jim Wilson wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
I created a patch on top of upstream binutils for a feature I need which
should be universally useful as well. Now I have 3 questions for you:
1) Does it look sane enough
On Mon, 8 Jun 2015, Jim Wilson wrote:
On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
Unless I'm missing something obvious, I can't find any section where all
options are documented together. There is the Invoking section but it
contains very few options
On Thu, 4 Jun 2015, Jim Wilson wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
I created a patch on top of upstream binutils for a feature I need which
should be universally useful as well. Now I have 3 questions for you:
1) Does it look sane enough
to .text sections that
need to stay resident.
This would also allow for actually omitting __exit sections from the Linux
kernel binary when modules are configured in even when exit marked code
generates exception table entries.
Signed-off-by: Nicolas Pitre n...@linaro.org
diff --git a/gas/ChangeLog b
nathan_ly...@mentor.com,
David Laight david.lai...@aculab.com,
Otavio Salvador ota...@ossystems.com.br,
Linus Torvalds torva...@linux-foundation.org,
Nicolas Pitre n...@fluxnic.net,
Linux OMAP Mailing List linux-o...@vger.kernel.org,
linux-arm-ker...@lists.infradead.org
Message-ID
On Mon, 2 Dec 2013, Riku Voipio wrote:
Hi,
According the debian bug report [1], it is not possible to use std::future
on armv5 targetting toolchains. This is because libstdc++ will only enable
std::future if ATOMIC_INT_LOCK_FREE 1. There is no LDREX for armv5 and
older, so this
On Sat, 6 Oct 2012, Mans Rullgard wrote:
On 5 October 2012 23:42, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
which is assumed to be
On Fri, 5 Oct 2012, Russell King - ARM Linux wrote:
On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
which is assumed to be aligned, and the cast overrides the packed attribute
from the struct.
Hello folks,
FYI
There is a thread on the arm-linux-kernel mailing list about a GCC bug,
and the Linaro version appears to be affected as well. Here's the
thread:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=186563
Nicolas
___
On Thu, 1 Sep 2011, Ulrich Weigand wrote:
Michael Hope michael.h...@linaro.org wrote:
On Thu, Sep 1, 2011 at 11:06 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
Hello Ulrich (or anyone else acquainted with gdb),
Could the gdb test suite be run on a kernel with the below patch
Hello Ulrich (or anyone else acquainted with gdb),
Could the gdb test suite be run on a kernel with the below patch applied
please? A confirmation that this patch doesn't regress gdb is required
before this can move ahead. Quick feedback would be greatly
appreciated.
Thanks.
--
Hello Michael,
We do have more and more instances of the following issues turning up in
the kernel requiring toolchain assistance to solve the problem properly.
Could you or someone from your team follow this up please?
-- Forwarded message --
Date: Tue, 1 Feb 2011 12:16:48
On Tue, 26 Apr 2011, Michael Hope wrote:
Hi Barry. I think the toolchain is operating correctly here. The
current version recognises a divide followed by a modulo and optimises
this into a call to the standard EABI function __aeabi__uldivmod().
Note the code:
do_div(Kpart,
On Wed, 20 Apr 2011, Dave Martin wrote:
Hi,
On Wed, Apr 20, 2011 at 1:42 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Wed, 20 Apr 2011, Dave Martin wrote:
On Tue, Apr 19, 2011 at 01:33:12PM -0400, Nicolas Pitre wrote:
You must not use static variable in the decompressor
On Wed, 20 Apr 2011, Shawn Guo wrote:
On Tue, Apr 19, 2011 at 04:23:09PM +0100, Dave Martin wrote:
Hopefully this explains what's going on, but what are you trying
to achieve exactly?
Thanks a ton, Dave. It does explain what I'm seeing, and your
explanation looks like a very good
On Tue, 19 Apr 2011, Dave Martin wrote:
So, if I understand correctly, because .bss doesn't take space in
the zImage, when the dtb is appended, it effectively ends up on top of
the bss/stack area?
Yes. However...
Since the compressed kernel loader knows how big bss and the stack
are, maybe
On Wed, 2 Mar 2011, Andrew Stubbs wrote:
On 02/03/11 17:52, Nicolas Pitre wrote:
Building a cross-compiler is already a challenge in itself. Would be
better to build a version that can be installed anywhere like the
CodeSourcery releases and offer that as a tar download.
Binaries
On Thu, 7 Oct 2010, Andrew Stubbs wrote:
There's another issue here: using a Linux user-space compiler to build for
bare-metal is a bad plan. libgcc is built assuming that system calls and
exceptions etc. work as they do in Linux user-mode. The Linux kernel is built
with a user-space compiler
On Wed, 6 Oct 2010, Michael Hope wrote:
...are available here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here:
http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license
25 matches
Mail list logo
