* Richard Biener:
>> + append (flags & SECTION_RELRO, "RELRO");
>> + append (flags & SECTION_EXCLUDE, "EXCLUDE");
>> + append (flags & SECTION_RETAIN, "RETAIN");
>> + append (flags & SECTION_LINK_ORDER, "LINK_ORDER");
>
> I'm not sure printing these internal flags is of help to the user.
There are cases where at least one of the conflicting sections is
internally created. I came through this via PR116887. In those cases,
the diagnostic is more of an ICE than a programmer error.
> So these are all cases where neither
>
> /* It is fine if one of the section flags is
> SECTION_WRITE | SECTION_RELRO and the other has none of these
> flags (i.e. read-only) in named sections and either the
> section hasn't been declared yet or has been declared as
> writable.
> In that case just make sure the resulting flags are
> SECTION_WRITE | SECTION_RELRO, ie. writable only because of
> relocations. */
> if (((sect->common.flags ^ flags) & (SECTION_WRITE | SECTION_RELRO))
> == (SECTION_WRITE | SECTION_RELRO)
> && (sect->common.flags
> & ~(SECTION_DECLARED | SECTION_WRITE | SECTION_RELRO))
> == (flags & ~(SECTION_WRITE | SECTION_RELRO))
> && ((sect->common.flags & SECTION_DECLARED) == 0
> || (sect->common.flags & SECTION_WRITE)))
> {
> sect->common.flags |= (SECTION_WRITE | SECTION_RELRO);
> return sect;
> }
> /* If the SECTION_RETAIN bit doesn't match, return and switch
> to a new section later. */
> if ((sect->common.flags & SECTION_RETAIN)
> != (flags & SECTION_RETAIN))
> return sect;
>
> matched. It should be possible to elaborate on the actual mismatch instead of
> dumping all of the random section flags?
Hmm. This part
&& (sect->common.flags
& ~(SECTION_DECLARED | SECTION_WRITE | SECTION_RELRO))
== (flags & ~(SECTION_WRITE | SECTION_RELRO))
seems to restrict the early return to the case where the internal flags
match. So I think we should print them in the general case. I could
special-case the LoongArch error (“attempt to mark an existing section
as RELRO”), but we can't say *what* causes this section type change
attempt in that particular case (it seems to come from constant pool
generation), so it's not going to be useful to programmers either way.
Thanks,
Florian
