[PATCH] D37736: [ELF] - Do not spread specific flags when emiting output sections.

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 6 16:08:32 PDT 2017


Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:

I am sorry it took me so long to get here, so let me try to summarize
this long review to give it a fresh start.

First thing: Yes, it still crashes.

It crashes because SHF_LINK_ORDER is added to a linker created
section. That breaks reasonable assumptions down the line. It seems
clear we should not be creating a dummy section with SHF_LINK_ORDER.

So, why are we creating dummy sections at all?

The issue what to do with linker script like

  .foo : { symbol = 42; } }

One option would be to convert it to

symbol = 42;

That is, move the symbol out of the empty section description. That
seems to be what bfd does for this simple case. The problem is that this
is not completely general. Bfd will give up and create a dummy section
too if there is a .=.+1 inside the section for example.

Given that we want to create the section, we have to worry what impact
it will have on the link. For example, if we just create a section with
0 for flags, it would change which PT_LOADs are created.

We could remember that that particular section is dummy and ignore it in
other parts of the linker. I tried that, but unfortunately there are
quite a few places that would need to change:

* The program header creation.
* The orphan section placement.
* The address assignment.

The other option is to pick flags that minimize the impact the section
will have on the rest of the linker. That is why we copy the flags from
the previous sections. That was simplistic, as only a few flags are
needed to keep the impact low, and copying more esoteric flags like
SHF_LINK_ORDER have the opposite effect: it causes undesirable effects
on the rest of the link.

Cheers,
Rafael


More information about the llvm-commits mailing list