Page MenuHomeFreeBSD

Fix booting the arm64 kernel when built with clang 3.9.0
ClosedPublic

Authored by andrew on Nov 23 2016, 11:45 AM.

Details

Summary

Clang 3.9.0 changes how weak extern is handled. They now use the got to
handle them. This is a problem as ld.bfd doesn't fill out any default
value in the got so pointers become NULL. This caused the kernel to fail
to boot as we use this in linker sets.

This fixes the issue by setting s default value in the got. The kernel
still loads data through it, but because we always load it at a fixed virtual
address the address it finds is valid.

There is an LLVM bug with some background information at the following,
however I think this is in fact a binutils bug the change in behaviour has
found.
https://llvm.org/bugs/show_bug.cgi?id=30848

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

andrew updated this revision to Diff 22460.Nov 23 2016, 11:45 AM
andrew retitled this revision from to Fix booting the arm64 kernel when built with clang 3.9.0.
andrew updated this object.
andrew edited the test plan for this revision. (Show Details)
andrew added a reviewer: bapt.
andrew added subscribers: emaste, dim.
emaste added a subscriber: jhb.Nov 23 2016, 4:18 PM

Post this for upstream binutils also? @jhb can commit it there if it's approved.

I'm not sure this is the correct fix for upstream. I don't think ld should be generating relocations for weak extern pointing at these linker sets, however that would need someone that knows more about ld internals than I do.

@bapt ping. rS309124 has updated clang breaking the arm64 kernel when built with binutils without this change.

gonzo added a subscriber: gonzo.Nov 27 2016, 8:19 PM
bapt accepted this revision.Nov 28 2016, 6:54 PM
bapt edited edge metadata.
This revision is now accepted and ready to land.Nov 28 2016, 6:54 PM

Patch tested successfully on my end.

This revision was automatically updated to reflect the committed changes.

I was trying to follow the discussion at llvm bug 30848, but the thread ran cold - there are still some unanswered investigation questions.