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 f
On Wed, 23 Dec 2015, Adhemerval Zanella wrote:
>
>
> > Em 22 de dez de 2015, às 14:22, Nicolas Pitre
> > escreveu:
> >
> >> On Mon, 21 Dec 2015, Jim Wilson wrote:
> >>
> >> I tracked the bulk of the patch back to April 2011, though some
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
> https://sourceware.org/ml/binutils/2011-04/msg00275.
Hello toolchain gurus,
In the course of Linaro's kernel tinification project, the ability to
compile the Linux kernel using LTO is a frequent requirement. However
the kernel makes heavy usage of 'ld -r' with .o files resulting from LTO
build of .c files as well as .o files resulting from pure a
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,
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
> >> wrote:
> >>
> >> On Thu, 4 Jun 2015, Jim Wilson wrote:
> >>
> >>> The
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 4511
On Mon, 8 Jun 2015, Jim Wilson wrote:
> On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre
> 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
>
On Thu, 4 Jun 2015, Jim Wilson wrote:
> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre
> 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
On Fri, 5 Jun 2015, Pinski, Andrew wrote:
> I am just going to say, I don't like this extension at all. It allows for
> abuse than it is good.
What abuses do you forsee? Could you elaborate please?
> Oh and why can't you use the C preprocessor to do this section
> renaming? I know for a fact
On Thu, 4 Jun 2015, Jim Wilson wrote:
> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre
> 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
tied 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
diff --git a/gas/ChangeLog b/gas/C
,
Linus Torvalds ,
Nicolas Pitre ,
Linux OMAP Mailing List ,
linux-arm-ker...@lists.infradead.org
Message-ID: <20141016001801.gq12...@n2100.arm.linux.org.uk>
Subject: Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote
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 def
On Sat, 6 Oct 2012, Mans Rullgard wrote:
> On 5 October 2012 23:42, 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 ca
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 wrote:
> > On Thu, Sep 1, 2011 at 11:06 AM, Nicolas Pitre
> wrote:
> > > Hello Ulrich (or anyone else acquainted with gdb),
> > >
> > > Could the gdb test suite be run on a kernel with th
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.
-- Forw
On Mon, 4 Jul 2011, Michael Hope wrote:
> On Mon, Jun 20, 2011 at 4:15 PM, Michael Hope wrote:
> > On Tue, Jun 14, 2011 at 9:03 AM, Nicolas Pitre
> > wrote:
> >> Hello Michael,
> >>
> >> We do have more and more instances of the following issu
On Mon, 20 Jun 2011, Arnd Bergmann wrote:
> On Saturday 18 June 2011, Nicolas Pitre wrote:
> > On Fri, 17 Jun 2011, Arnd Bergmann wrote:
>
> > > If I understood Uli correctly, it should be possible to express this
> > > with gcc syntax, but of course there may be a
On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> On Friday 17 June 2011, Michael Hope wrote:
> > Hi Paolo. I've had a look into this and updated the ticket. The
> > problem is due to a change in behaviour between 4.5 and 4.6 when
> > accessing strcuts marked with __attribute__((packed)). 4.5 would d
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 +000
On Wed, 27 Apr 2011, Michael Hope wrote:
> On Wed, Apr 27, 2011 at 12:23 AM, Andrew Stubbs
> wrote:
> > On 26/04/11 03:39, Nicolas Pitre wrote:
> >>
> >> But I digress. This is just to say that gcc shouldn't pull
> >> __aeabi_uldivmod in this case bec
On Tue, 26 Apr 2011, Michael Hope wrote:
> Yip, so the compiler spots these two lines:
> Ndiv = target / source;
> Nmod = target % source;
>
> and turns them into
> Ndiv, Nmod = __aeabi_uldivmod(target, source)
Why would gcc do that? All four variables involved here are of t
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, s
On Wed, 20 Apr 2011, Dave Martin wrote:
> Hi,
>
> On Wed, Apr 20, 2011 at 1:42 PM, Nicolas Pitre
> 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
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. For one thing,
> > that breaks the ability to XIP the decompressor code and move writable
> > data elsewhere
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, m
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 go
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 t
On Wed, 2 Mar 2011, Dave Martin wrote:
> On the other hand, the cross toolchain packages are likely to be of
> interest to such visitors, but aren't obviously advertised -- maybe
> I'm looking in the wrong place, but if so then new visitors to the
> linaro pages are likely to look in the wrong pla
I just stumbled across this:
http://article.gmane.org/gmane.comp.debugging.openocd.devel/15584
And the mentioned clock issue seems to be fixed here:
http://article.gmane.org/gmane.comp.debugging.openocd.devel/15619
This is excellent news, and I think we ought to support this at some
point.
N
know that it cannot be reliable as is.
> 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 g
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 already and needs to be fixed regardless.
Motivations for the removal of PTRACE_SINGLESTEP on ARM are:
1.) Only a subs
On Fri, 3 Dec 2010, Dave Martin wrote:
> On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi wrote:
> > Hi, Kernel WG,
> > Can recent kernel handle NEON registers in corefiles?
> >
> > Seems we've had plan for this in "Ensure full NEON debug support" in
> > https://wiki.linaro.org/WorkingGroups/KernelConsolid
On Mon, 22 Nov 2010, Dave Martin wrote:
> So I've now come round to the view that we _should_ probably bite the
> bullet and fix the inline asm directly. So:
>
>* We need to verify which binutils permit (and ignore) the IT
> instructions in non-unified (ARM) syntax. I've observed that 2.19.
People here might want to have a look at this bug:
http://gcc.gnu.org/bugzilla/show_bg.cgi?id=45979
Note that the heap randomization feature added to the kernel was part of
a Linaro security blueprint.
Nicolas
___
linaro-toolchain mailing li
On Tue, 12 Oct 2010, Michael Hope wrote:
> Ah, I see. You use the JTAG unit and on-chip debug hardware for the
> kernel and use the JTAG-supplied DCC connection for applications. So
> you can use the DCC instead of Ethernet or serial, which is nice as it
> frees up a port.
>
> You might want to
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 compi
On Wed, 6 Oct 2010, Michael Hope wrote:
> Ah, there's all types of things going on here. It's an unusual one as
> string routines such as memcpy() are fundamental and self contained
> and pointless to reimplement. I want to share them almost as a gift,
> usable by anyone under any terms and, ide
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 licens
On Tue, 21 Sep 2010, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > Is the specific tool chain in question available somewhere
> > > for testing?
> >
> > As far as I know, any reasonably recent toolcha
On Tue, 21 Sep 2010, Wolfgang Denk wrote:
> Is there any information available about relative code sizes /
> performance numbers of "--emit-relocs" versus "--use-blx"?
The blx instruction will always win on both counts: it is smaller and
faster than a veneer.
> BTW: why does nobody answer my qu
On Mon, 20 Sep 2010, Zach Welch wrote:
> Hi all,
>
> I was recently hired by CodeSourcery and have been assigned to Linaro
> for the purpose of improving OpenOCD.
Welcome! Glad to meet you in the context of OpenOCD again.
Nicolas
___
linaro-toolcha
On Thu, 9 Sep 2010, Andrew Stubbs wrote:
> On 09/09/10 16:22, Yao Qi wrote:
> > GCC produces code like this,
> > 0024:
> >24: f000 000f and.w r0, r0, #15
> >28: 2807cmp r0, #7
> >2a: d901bls.n 30
> >2c: 3810subsr0, #
On Mon, 6 Sep 2010, Yao Qi wrote:
> Yao Qi wrote:
> > Hi,
> > We are looking for some possible improvements and optimizations on
> > thumb2 code size. Currently, I am running some benchmarks with
> > compilation flag "-Os -march=armv7-a -mthumb", and hope to find some
> > thing interesting that w
47 matches
Mail list logo
