https://sourceware.org/bugzilla/show_bug.cgi?id=33779
Jan Beulich <jbeulich at suse dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #3 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Jason Andryuk from comment #2)
> 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.
Just that the use of groups changes the picture.
> 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?
No, and I wonder if this isn't a bug. Cc-ing Alan, who iirc did quite a bit of
the groups work.
> Does that matter, when they are output as a single section?
Is this question related to "gas-internal" in the earlier question? All
sections recorded separately internally are also output separately, afaik.
Sub-sections is where this is different. Like .init.text, if multiple .text
were recorded internally, multiple .text would also appear in the output.
> Using groups in the lookup when they are not specified is a different
> behavior from .text which "just works", AFAICT.
See above - may be a bug really. (Whether the behavior could sensibly be
changed now is a separate question.)
> 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.
Funny you should mention that: Did it occur to you that the section() attribute
doesn't work properly with -ffunction-sections? That attribute should really
only be (possible to be) a template (perhaps in general, but particularly when
the option is used), for the function name (or more generally: the nominal
section name) to then be applied as requested. Already years ago I was
wondering whether to enter a bug for that.
> 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.
If the flags were to be re-used, why create a separate section?
> Maybe that is too subtle? But all sections of the same name having the same
> flags, regardless of group, seems reasonable to me.
Yet that would undermine .attach_to_group: One may want to use a different one
for the 2nd instance. (I don't expect you're suggesting to inherit flags but
not the group.)
> I tried __attribute__((__section__((".init.text.%S")))), but the compiler
> still only specifies the flags on the first .section instance.
Plus the resulting section name would then depend on whatever earlier section
was in use.
> 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.
Something pretty similar came up several years ago:
https://sourceware.org/pipermail/binutils/2019-July/107528.html. Thing is that
even just language-wise I can't really see how to sensibly implement such an
"inquiry". The only, pretty clumsy, approach I could think of would be variants
of .if (along the lines of e.g. .ifeqs), perhaps with some wildcard matching
support.
Overall, as per a remark above, I think that this wants (primarily) sorting at
the compiler side, not at the assembler one. (Then of course gcc and clang
would want keeping in sync.)
--
You are receiving this mail because:
You are on the CC list for the bug.
