[PATCH v2 08/28] gas/write.c: add missing flag SEC_HAS_CONTENT on object attributes section

[Michael Matz]

Hello,

On Wed, 7 May 2025, Matthieu Longo wrote:

> Creating the same section but with different flags depending on where it is
> created, seemed very strange to me.

It isn't _that_ strange, though.  The linker has to deal with many more 
cases for creating sections compared to either the assembler, or things 
like objcopy.  Sections in the linker can come from the input files, can 
be artificially created, can result from combining several sections, and 
can come from linker scripts, and from combinations of those cases.  GAS 
always creates sections from nothing.  So, I wouldn't always worry 
about different flags when creating sections, but perhaps use it as 
investigate-me nudge :-)  (In this specific case, you have a valid point 
it turns out, see the bottom)

> ### SEC_ALLOC and SEC_LOAD
> 
> > There's no SHF_* counterpart to SEC_HAS_CONTENTS. Whereas e.g.
> > _bfd_elf_make_section_from_shdr() derives SEC_HAS_CONTENTS from the
> > section type not being SHT_NOBITS.
> 
> I am trying to make sense of what you mean here.
> I found in https://refspecs.linuxbase.org/elf/gabi4+/ch4.sheader.html, Figure
> 4.11 those SHF_* flags, and when I compare them to the list of flags in
> bfd/bfd.h, I am really lost.
> 
> I don't understand what the following comments mean:
> 
>   /* Tells the OS to allocate space for this section when loading.
>      This is clear for a section containing debug information only.  */
> #define SEC_ALLOC                         0x1
> 
>   /* Tells the OS to load the section from the file when loading.
>      This is clear for a .bss section.  */
> #define SEC_LOAD                          0x2
> ...
> 
> What does "This is clear" mean here ? Because one thing is sure, it is not
> clear at all.

These are descriptions of flags, so "is clear" in this context means "the 
flag isn't set".  So: "SEC_ALLOC is unset for a section containing only 
debug information", and so on.  

> What is the difference between SEC_ALLOC and SEC_LOAD ? Does SEC_LOAD mean
> that the content is loaded from the file ? Does SEC_ALLOC mean that the
> section is allocated but empty (=no content is loaded from the file) ? 

Yes.

> If this is correct, why are there 2 different flags because one seems to 
> mean the opposite so one flag would be enough ?

There a non-LOAD, non-ALLOC sections, like debug_info, so the flags aren't 
the reverse of each other.

> How do those two previous flags align with SHF_ALLOC which means that the
> section occupies memory during process execution ?

SHF_* flags are the ELF section flags, the SEC_* constants are 
BFD-internal sections flags, that roughly match to those (and also to 
similar flags from other file formats like PE-coff).  Occasionally the 
match isn't 100%, but for ALLOC it is: the flag is set in ELF 
files for sections for which address space has to be reserved at execution 
load time, SEC_ALLOC has the same meaning.  Hence, on read-in in the 
linker SEC_ALLOC is set when SHF_ALLOC was.

For SEC_LOAD it's a little different: in BFD speak it's a single flag, but 
in ELF speak it's a section type _plus_ flag: SHT_PROGBITS+SHF_ALLOC (or 
actually, non-SHT_NOBITS + SHF_ALLOC at read-in).

HAS_CONTENTS is still different: there's no equivalent in ELF, rather it's 
BFD-internal only.  It roughly means that section->contents and 
section->size are meaningful and can hold blobs representing the 
sections contents.  For instance it would be set for sections like .data 
(in addition to SEC_LOAD|SEC_ALLOC) but also for .debug_info (and there 
without LOAD or ALLOC).  Sections with this flag would be written out by 
BFD to the to-be-produced output file (based on further conditions).

> Since SEC_HAS_CONTENTS derives from not(SHT_NOBITS), how is it wrong to 
> set this value inside the assembler ?

It may not be wrong to set it in GAS, in fact here it is the right thing: 
maybe_generate_build_notes also does so, and the obj_attr sections seem to 
be in the same league.  Further it's the case that 
bfd_set_section_contents _must_ be used only with sections that has 
SEC_HAS_CONTENTS set before calling it.  That function is ultimately used 
by create_obj_attrs_section via bfd_elf_set_obj_attr_contents, and so the 
section should better have that flag set.  If 
bfd_elf_set_obj_attr_contents would check errors on the functions it calls 
this would have be seen earlier already I guess.

I hope that help.


Ciao,
Michael.