[PATCH] Section Anchors and named sections
Mon Apr 24 06:23:00 GMT 2006
David Edelsohn <firstname.lastname@example.org> writes:
> I agree that having anchors in named sections makes sense. The
> problem is that there are more ways to create DECLs with unique sections
> than DECL_ONE_ONLY. Specifically, resolve_unique_section() logic is:
> if (DECL_SECTION_NAME (decl) == NULL_TREE
> && targetm.have_named_sections
> && (flag_function_or_data_sections
> || DECL_ONE_ONLY (decl)))
> targetm.asm_out.unique_section (decl, reloc);
> so either flag_data_sections or DECL_ONE_ONLY. The section anchor logic
> specifically excludes DECL_ONE_ONLY DECLs:
> /* There's no point using object blocks for something that is
> isolated by definition. */
> if (DECL_ONE_ONLY (decl))
> return NULL;
> but DECLs placed in unique sections are not skipped.
Right. I was actually half-persuaded by the idea of your original
patch. It shouldn't have been needed for correctness, but like you say,
it would reduce the amount of waste. (The amount of waste is quite small
compared to what we already need for per-decl sections; we already need
a section structure and section name, for instance. But that's no
excuse not to do avoid the waste if it's easy to do.)
The only thing that seemed wrong from a waste-reduction point of
view was that you didn't reproduce all of the resolve_unique_section
condition; there was no check for whether DECL_SECTION_NAME was null.
With that change, I don't see how it could have a negative effect,
but it sounds like I'm missing something.
> With the change to apply DATA_ALIGNMENT to section anchor block
> DECLs, the files will compile correctly, but GCC can produce anchors in
> unique sections.
Thanks for the great explanation (snipped). In that case, I agree
with the alignment part of your patch. I can't approve it of course.
More information about the Gcc-patches