https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #24 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #23) > Comment on attachment 45830 [details] > proposed patch > > Please update the get_block_for_section function comment accordingly: > > /* Return the object_block structure for section SECT. Create a new > structure if we haven't created one already. Return null if SECT > itself is null. */ > > This should say that we return NULL also for mergeable sections and why > - that section anchors can't be used in mergeable sections anyway, because > the linker might move objects around, and that using the object blocks > infrastructure in that case is both a waste and maintenance burden. I think we should also remove the test in default_use_anchors_for_symbol_p, since: sect = SYMBOL_REF_BLOCK (symbol)->sect; will surely fault if the block is null. Agree the patch looks good with those changes. > Given: > /* Don't use anchors for small data sections. The small data register > acts as an anchor for such sections. */ > if (sect->common.flags & SECTION_SMALL) > return false; > we could do the same for SECTION_SMALL, but I'm not suggesting that ATM. The idea was that the block infrastructure could also be used at some future time to organise decls into a specific order, e.g. to promote locality. Obviously that hasn't happened yet, but I think we should keep the SECTION_SMALL stuff as-is and only exclude decls that can't be put into blocks for correctness reasons. In general, the section anchor/section block stuff could probably be cleaned up a lot now that unit-at-a-time is the only supported mode. (That wasn't true when it was originally written.)
