On Wed, Nov 04, 2020 at 03:58:56PM -0800, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 3:00 PM Hans-Peter Nilsson <h...@bitrange.com> wrote:
> >
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson <h...@bitrange.com>
> > > wrote:
> > > > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > >
> > > > > On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson <h...@bitrange.com>
> > > > > wrote:
> > > > > >
> > > > > > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > > > > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson
> > > > > > > <h...@bitrange.com> wrote:
> > > > > > > > I'm not much more than a random voice, but an assembly directive
> > > > > > > > that specifies the symbol (IIUC your .retain directive) to
> > > > > > >
> > > > > > > But .retain directive DOES NOT adjust symbol attribute.
> > > >
> > > > I see I missed to point out that I was speaking about the *gcc
> > > > symbol* attribute "used".
> > >
> > > There is no such corresponding symbol attribute in ELF.
> >
> > I have not missed that, nor that SHF_GNU_RETAIN is so new that
> > it's not in binutils master. I have also not missed that gcc
> > caters to other object formats too. A common symbol-specific
> > directive such as .retain, would be better than messing with
> > section attributes, for gcc.
>
> This is totally irrelevant to SHF_GNU_RETAIN.
>
> > > > It's cleaner to the compiler if it can pass on to the assembler
> > > > the specific symbol that needs to be kept.
> > > >
> > >
> > > SHF_GNU_RETAIN is for section and GCC should place the symbol,
> > > which should be kept, in the SHF_GNU_RETAIN section directly, not
> > > through .retain directive.
> >
> > This is where opinions differ. Anyway, this is now repetition;
> > I'm done.
>
> .retain is ill-defined. For example,
>
> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> static int xyzzy __attribute__((__used__));
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.c"
> .text
> .retain xyzzy <<<<<<<<< What does it do?
> .local xyzzy
> .comm xyzzy,4,4
> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> .section .note.GNU-stack,"",@progbits
> [hjl@gnu-cfl-2 gcc]$
>
> A symbol directive should operate on the symbol table.
> With 'R' flag, we got
>
> .file "x.c"
> .text
> .section .bss.xyzzy,"awR",@nobits
> .align 4
> .type xyzzy, @object
> .size xyzzy, 4
> xyzzy:
> .zero 4
> .ident "GCC: (GNU) 11.0.0 20201104 (experimental)"
> .section .note.GNU-stack,"",@progbits
I still think it is very wrong for the "used" attribute to place the
symbol in a unique section. The structure of the sections in the object
file should be no different whether the "used" attribute was applied to
a symbol or not.
I will therefore have to make changes to GCC so that we can get the name
of "unnamed" sections, and emit a .section directive with the "R" flag
set on that section name, in order to avoid using a .retain directive.
"used" applied to a function
---
Before:
TEXT_SECTION_ASM_OP
func:
After:
.section TEXT_SECTION_NAME,"axR",%progbits
func:
Where TEXT_SECTION_NAME is a new macro which defines the section name
corresponding to TEXT_SECTION_ASM_OP.
Similar new macros are required for all *SECTION_ASM_OP.
Since we can't use the .retain directive, this is the cludge that will
be required to robustly support all targets.
The alternative is to just infer that the mapping of unnamed sections to
section names is always the following:
text_section -> .text,"ax",%progbits
data_section -> .data,"aw"
bss_section -> .bss,"aw",%nobits
rodata_section -> .rodata,"a",
etc.
This section name assumption does not hold for a couple of ELF targets.
Also, many targets omit the specification of the flags, leaving that
choice to the assembler, instead the compiler will now have to infer
what the assembler will do, all because we can't have the .retain
directive.
.retain <symname> makes life very easy for GCC, but I understand your
objection from a theoretical point of view.
You previously objected to .retain <section_name>, to apply
SHF_GNU_RETAIN to <section_name>. This does not violate your rule about
a directive applying flags to a different type of structure to what is
named in the directive.
If we can have .retain <section_name>, then we don't have to make
assumptions about section flags in GCC, we can just name the section use
in the ASM_OP.
Do you still oppose .retain <section_name>?
Another alternative is to disallow "used" from applying SHF_GNU_RETAIN,
unless the symbol is in a named section. Obviously this is pretty gross,
but would mean we don't need to handle *SECTION_ASM_OP sections.
Thanks,
Jozef
>
> --
> H.J.
