On 2/18/21 3:19 AM, Richard Biener via Binutils wrote:
> On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz
> wrote:
>> On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches
>> wrote:
>>> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
When build
On Thu, Feb 18, 2021 at 03:38:46PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Feb 18, 2021 at 02:22:35PM +, Jozef Lawrynowicz wrote:
> > I think it is a enhancement, and true to the spirit of the attribute,
> > for "used" to save a symbol from linker garbage collection.
> >
> > Why
On Thu, Feb 18, 2021 at 02:22:35PM +, Jozef Lawrynowicz wrote:
> I think it is a enhancement, and true to the spirit of the attribute,
> for "used" to save a symbol from linker garbage collection.
>
> Why should "used" mean:
> Save this symbol from compiler optimization, but allow the linker
On Thu, Feb 18, 2021 at 01:08:54PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Feb 18, 2021 at 12:00:59PM +, Jozef Lawrynowicz wrote:
> > If we can add ".retain " to GAS, then I agree, current GCC
> > SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage
> > .retain to imp
On Thu, Feb 18, 2021 at 11:22:42PM +1030, Alan Modra via Binutils wrote:
> On Wed, Feb 17, 2021 at 11:23:12AM +, Jozef Lawrynowicz wrote:
> > In previous discussions, it seemed to me that there was general support
> > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from
> >
On Wed, Feb 17, 2021 at 11:23:12AM +, Jozef Lawrynowicz wrote:
> In previous discussions, it seemed to me that there was general support
> for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from
> linker garbage collection[1]. Of course, the current implementation
> results in
On Thu, Feb 18, 2021 at 12:00:59PM +, Jozef Lawrynowicz wrote:
> If we can add ".retain " to GAS, then I agree, current GCC
> SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage
> .retain to implement the functionality where "used" saves symbols form
> linker garbage collection, w
On Thu, Feb 18, 2021 at 11:19:50AM +0100, Richard Biener via Binutils wrote:
> On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz
> wrote:
> >
> > On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-pat
On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz
wrote:
>
> On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> > > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> >
On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> > thousands of
> >
> > ld: warning: orphan section `.data.event_ini
On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> thousands of
>
> ld: warning: orphan section `.data.event_initcall_finish' from `init/main.o'
> being placed in section `.data.event_initcall_finish'
When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
thousands of
ld: warning: orphan section `.data.event_initcall_finish' from `init/main.o'
being placed in section `.data.event_initcall_finish'
ld: warning: orphan section `.data.event_initcall_start' from `init/main.o'
being
12 matches
Mail list logo