This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Do not use mergeable sections when LS is used.
ClosedPublic

Authored by grimar on Aug 12 2016, 5:47 AM.

Details

Summary

After latest changes we combine input sections with different attributes into
single output section.
Problem here is that regular output sections does not
support adding mergeable input sections (and vise versa).
Patch just disables merging for now at the same way we do for -O0 for example.

This change helps for linking FreeBSD kernel.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar updated this revision to Diff 67825.Aug 12 2016, 5:47 AM
grimar retitled this revision from to [ELF] - Do not use mergeable sections when LS is used..
grimar updated this object.
grimar added a reviewer: ruiu.
grimar added subscribers: llvm-commits, grimar, evgeny777, davide.

This seems to me just a way to avoid a bug, that needs to be fixed.

This seems to me just a way to avoid a bug, that needs to be fixed.

We use the same for -O0 currently. Of cource it should be implemented, but for now that is easy way to go forward in supporting LS.

"This change helps for linking FreeBSD kernel."

Can you please elaborate? Have you tried booting and you are able to boot a running kernel with this change, and without you're not able to?

This seems to me just a way to avoid a bug, that needs to be fixed.

We use the same for -O0 currently. Of cource it should be implemented, but for now that is easy way to go forward in supporting LS.

That's a completely different story. -O0 has an explicit semantic which is "linker please do not optimize my code".
Here we're silently skipping the optimization because nobody implemented the correct support for it. So, sure, you can do this as temporary workaround (although I disagree because it hides a bug), but I wouldn't say that "we do this at -O0" is a justification for this or being sloppy.

grimar added a comment.EditedAug 12 2016, 6:14 AM

"This change helps for linking FreeBSD kernel."

Can you please elaborate? Have you tried booting and you are able to boot a running kernel with this change, and without you're not able to?

I did not try booting yet, because there are still problems with linking. Without this change linker just crashes in

void OutputSection<ELFT>::addSection(InputSectionBase<ELFT> *C)
..
auto *S = cast<InputSection<ELFT>>(C); // Here

because we are trying to add MergeInputSection.

After that change in combination with other patches that are on review at least lld completes linking. And there are post-link issues still:

BFD: stdON5Bm: section `.eh_frame' can't be allocated in segment 4
objcopy: stdON5Bm: Bad value
BFD: stdON5Bm: section `.eh_frame' can't be allocated in segment 4

This seems to me just a way to avoid a bug, that needs to be fixed.

We use the same for -O0 currently. Of cource it should be implemented, but for now that is easy way to go forward in supporting LS.

That's a completely different story. -O0 has an explicit semantic which is "linker please do not optimize my code".
Here we're silently skipping the optimization because nobody implemented the correct support for it. So, sure, you can do this as temporary workaround (although I disagree because it hides a bug), but I wouldn't say that "we do this at -O0" is a justification for this or being sloppy.

I think "we do that for -O0" is a justification for correctness of the change. Main reason for this is to let kernel to link. More complex change will need more time for reviews and I think we can use this one as temporarily solution.

This seems to me just a way to avoid a bug, that needs to be fixed.

We use the same for -O0 currently. Of cource it should be implemented, but for now that is easy way to go forward in supporting LS.

That's a completely different story. -O0 has an explicit semantic which is "linker please do not optimize my code".
Here we're silently skipping the optimization because nobody implemented the correct support for it. So, sure, you can do this as temporary workaround (although I disagree because it hides a bug), but I wouldn't say that "we do this at -O0" is a justification for this or being sloppy.

I think "we do that for -O0" is a justification for correctness of the change. Main reason for this is to let kernel to link. More complex change will need more time for reviews and I think we can use this one as temporarily solution.

No, it isn't. If any, the kernel link line should be changed to contain -O0 until proper support is implemented and not the other way around.

Also, please note that I'm not entirely opposed with the workaround (although I don't agree with that either), so I'll defer the judgment to others. What kinda bothers me is your justification for this change, which does make absolutely no sense to me.

Also, please note that I'm not entirely opposed with the workaround (although I don't agree with that either), so I'll defer the judgment to others. What kinda bothers me is your justification for this change, which does make absolutely no sense to me.

Ok. Just in case I am also working on a real patch for this at this moment.
My point was that LS is still feature heavely under development and latest commits shows that sometimes we can use temporarily workarounds when we know it is not harmfull.

ruiu edited edge metadata.Aug 12 2016, 11:20 AM

Because currently our linker script support is incomplete and broken, it is okay to break something to fix something temporarily as long as we are making a progress. Speaking of this patch, it is okay to submit this and remove later, so please check this in if you want.

ruiu added a comment.Aug 12 2016, 11:23 AM

But the problem you are trying to fix is a hard one in my opinion. Currently, we instantiate input sections when we read them from files, so the decision whether the sections are to be string-merged or not is made when we read files. That's too early if you allow linker scripts to combine non-mergeable sections with mergeable ones. I do not have a clear idea how to deal with this. If you have an idea, and if it's going to be a large change, please discuss before writing a patch.

In D23447#514076, @ruiu wrote:

But the problem you are trying to fix is a hard one in my opinion. Currently, we instantiate input sections when we read them from files, so the decision whether the sections are to be string-merged or not is made when we read files. That's too early if you allow linker scripts to combine non-mergeable sections with mergeable ones. I do not have a clear idea how to deal with this. If you have an idea, and if it's going to be a large change, please discuss before writing a patch.

Yep, I also today faced it is not trivial task. At first I thought it is possible to convert mergable section to regular, but probably better would be to create regular ones at the begining.
I have no good ideas how to do that without early sections scan. Will revisit this later.

This revision was automatically updated to reflect the committed changes.