This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Bypass section type check #2
ClosedPublic

Authored by evgeny777 on Jan 30 2017, 5:55 AM.

Diff Detail

Event Timeline

evgeny777 created this revision.Jan 30 2017, 5:55 AM

FWIW, I liked the spirit, if not the implementation, of your original change: https://reviews.llvm.org/D28761. To me it seems that LLD should do it's best to obey the linker script even if that means producing an elf that doesn't meet the elf standard (although I think it is a dubious call as to if the elf standard is really meant to be this strict). By all means issue a warning if the types or flags of sections don't match - but don't fail the link! This makes the tool simpler and able to cope with non-conforming input effectively.

I see. I'm not sure about the motivation behind those flag/type checks. @grimar has just found out that they prevent linux kernel from linking ....

I see. I'm not sure about the motivation behind those flag/type checks. @grimar has just found out that they prevent linux kernel from linking ....

Yes I tried to fix it in a some nice way at first, but found my solution will not work. So issue is next:

# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
# RUN: echo "SECTIONS { .notes : { *(.note.*) } }" > %t.script
# RUN: ld.lld --script %t.script --build-id %t.o -o %t

## Check that synthetic .note.gnu.build-id links fine with non-alloc note.
.section .note.1
.quad 0

Testcase above should work. Linux kernel contains script:

.notes : AT(ADDR(.notes) - 0xffffffff80000000) { __start_notes = .; *(.note.*) __stop_notes = .; } :text :note

and called with --build-id.

We create allocatable synthetic section .note.gnu.build-id and fail to combine it with other non allocatable sections .note.*
At first I tried to ignore check for synthetic input sections, but that will not work in general case.

Now I am not sure what is good solution for that.

davidb added a subscriber: davidb.Jan 30 2017, 9:14 AM

I think these checks exist, because of this line from the gabi.

In the first phase, input sections that match in name, type and attribute flags should be concatenated into single sections.

However, it should be noted that this is followed by an note that states that linkers are only recommended to follow this approach.

AFAIR: at least gnu does not follow this rule. Also, I am aware of many codebases (games) with hand written asm which does not set the section flags correctly. This is not always easy to fix. Perhaps this asm is in a third party library etc..

Being permissive on this can be very helpful to users.

discussion continued via email:

Rafael Avila de Espindola <rafael.espindola@gmail.com>
5:49 PM (15 hours ago)

to reviews+D29278., eleviant, ruiu, seifsta, me, llvm-commits, ikudrin.dev, grimar, adhemerval.zan. 
ben via Phabricator <reviews@reviews.llvm.org> writes:

> bd1976llvm added a comment.
>
> I think these checks exist, because of this line from the gabi.
>
>   In the first phase, input sections that match in name, type and attribute flags should be concatenated into single sections.
>
> However, it should be noted that this is followed by an note that states that linkers are only **recommended ** to follow this approach.
>
> AFAIR: at least gnu does not follow this rule. Also, I am aware of many codebases (games) with hand written asm which does not set the section flags correctly. This is not always easy to fix. Perhaps this asm is in a third party library etc..
>
> Being permissive on this can be very helpful to users.

And that is the idea of the white list. It makes us as permissive as we
need. I also don't see the point for different levels depending on
linker scripts being used or not.

Cheers,
Rafael

bd1976 llvm <bd1976llvm@gmail.com>
6:19 PM (15 hours ago)

to Rafael 
Unless your not permissive enough! Most permissive is just to obey the linker script and warn if doing so might cause issues. The tool gains more functionality and doesn't sacrifice safety. Linker script primacy FTW :)


Rafael Avila de Espindola
6:25 PM (14 hours ago)

to me 
That means we would never find out if something we are allowing is
needed and way. We should not extend the white list unless there is a
good reason for it.
This revision was automatically updated to reflect the committed changes.
ELF/OutputSections.cpp