On Wed, 2 Dec 2020, H.J. Lu via Gcc-patches wrote:
> > Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or
> > related macros need to change to work with both old and new GCC.
>
> We may need to update glibc for GCC 11. Can you open a glibc bug and
> CC me?
https://source
On Wed, Dec 2, 2020 at 1:31 PM Joseph Myers wrote:
>
> This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has
> broken the glibc build (at least with current binutils master). The
> errors are of the form:
>
> In file included from :
> gconv_dl.c: In function 'free_mem':
> gconv_dl.
This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has
broken the glibc build (at least with current binutils master). The
errors are of the form:
In file included from :
gconv_dl.c: In function 'free_mem':
gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with
...
>>> int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
>>>
>>> and 2 additional tests for -fcommon.
>>>
>>> Thanks.
>>>
>>>
>>> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>>>
nd 2 additional tests for -fcommon.
> >
> > Thanks.
> >
> >
> > 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
> >
> > From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu"
> > Date: Mon
uot;" } } */
> ...
> int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
>
> and 2 additional tests for -fcommon.
>
> Thanks.
>
>
> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>
> From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb
-fcommon.
Thanks.
--
H.J.
From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Mon, 3 Feb 2020 11:55:43 -0800
Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
In assemly code, the section flag 'R' sets the SHF_GNU_
On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done. Here is the updated patch.
Hi. I see a test-case for this kind of construct:
int foo __attribute__((__used__, __section__ (".bar"))) = 42;
and IIUC that it's handled as I'd hope (setting "R" on the named
section, not another derived
ith the "section" attribute applies the
> "R" flag. Please apply the attached patch if this gets approved. These
> new tests pass with arm-none-eabi and x86_64-pc-linux-gnu.
>
Done. Here is the updated patch.
--
H.J.
From 07c4c78c43d3b94e56d6ace97b660c69998011e4 Mon
On Thu, Nov 12, 2020 at 02:41:52PM -0800, H.J. Lu wrote:
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 435c7b348a5..c48ef9692ee 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -289,6 +289,10 @@ get_section (const char *name, unsigned int flags, tree
> decl,
>slot = section_htab->fin
In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
indicate that the section must be preserved by the linker.
Add SECTION_RETAIN to indicate a section should be retained by the linker
and set SECTION_RETAIN on section for the preserved symbol if assembler
supports SHF_GNU_RETAIN
11 matches
Mail list logo
