https://sourceware.org/bugzilla/show_bug.cgi?id=33779
--- Comment #2 from Jason Andryuk <jason.andryuk at amd dot com> ---
I find the behaviour unexpected. In the "normal" case:
.section .init.text,"ax",@progbits
...
.section .init.text
The second section re-uses the first. Once the first section is attached to a
group, the second lookup fails. I'd think it reasonable to re-use the flags
from the first one.
On the other hand, multiple .text lines seem to do what is expected. I assume,
.text implicitly uses "ax",@progbits flags, so each one has the expected flags.
Is this creating multiple gas-internal sections? Does that matter, when they
are output as a single section?
Using groups in the lookup when they are not specified is a different behaviour
from .text which "just works", AFAICT.
In light of all that, .attach_to_group doesn't seem particularly useful. If it
can't work via inline assembly with the compiler, then why have it? When
writing assembly code, you can just write the group explicitly in .section, and
there is no reason for .attach_to_group. It seems it was created to use with
-ffunction-sections and without consideration for manually specified sections.
For usability, I wonder if gas could track the section internally with a
"no-group-initially" flag, and allow that to be matched for bare section names.
Not to re-use the section, but instead to just grab the flags. Maybe that is
too subtle? But all sections of the same name having the same flags,
regardless of group, seems reasonable to me.
I tried placing all .init.text functions consecutively, so only a single
.section with flags is emitted. In a simple case that works, but it'll break
quickly when the compiled emits .section .rodata in between.
I tried __attribute__((__section__((".init.text.%S")))), but the compiler still
only specifies the flags on the first .section instance.
I wondered about hacking around by checking if current section is ".init.text",
and skipping .attach_to_group for that case. But I don't see a way to get the
current section name.
This also fails without .attach_group:
.section .init.text,"axG",@progbits,.init.text
...
.section .init.text
Sure, maybe not a bug. I guess I always expected ".section .foo" to refer back
to the previously defined .section .foo + flags.
--
You are receiving this mail because:
You are on the CC list for the bug.
