This is an archive of the discontinued LLVM Phabricator instance.

Relocation to discarded section from .gcc_except_table is alright
AbandonedPublic

Authored by tmsriram on Oct 29 2020, 12:51 PM.

Details

Summary

I saw a "Relocation to discarded section" warning in lld from .gcc_except_table to a COMDAT basic block section and this patch makes lld ignore this.

With --emit-relocs, lld safely ignores such relocations: https://github.com/llvm/llvm-project/blob/master/lld/ELF/InputSection.cpp#L453 whereas it doesn't do so in the normal case of scan relocations : https://github.com/llvm/llvm-project/blob/master/lld/ELF/Relocations.cpp#L966

I ran into this problem with basic block sections. Here is a repro for the problem and I have attached a very condensed test that pretty much does the same thing.

foo.cc

#include <iostream>
using namespace std;

inline int foo () {

try {
  foo();
} catch (const char* msg) {
}
return 0;

}
int bar();
int main() {

cerr << &foo;
return 0;

}

bar.cc
#include <iostream>
using namespace std;

inline int foo() {

return 0;

}

int bar() {

cerr << &foo;
return 0;

}

Now,

$ clang++ -fbasic-block-sections=all -funique-basic-block-section-names -c foo,cc
$ clang++ -fbasic-block-sections=all -funique-basic-block-section-names -c bar.cc

Now link with bar.o before foo.o
$ clang++ -fuse-ld=lld bar.o foo.o
error: relocation refers to a discarded section: .text._Z3foov._Z3foov.2

foo.o(gcc_except_table)

Reason is that foo.o uses exceptions and .gcc_except_table has a relocation pointing to a bb section there whereas the COMDAT copy in bar.o does not. Since that is kept, we see the error. gcc_except_table cannot be placed in the COMDAT group so this can be safely ignored.

Infact, the code in copy relocations shows that it can be ignored safely.

Diff Detail

Event Timeline

tmsriram created this revision.Oct 29 2020, 12:51 PM
tmsriram requested review of this revision.Oct 29 2020, 12:51 PM

I think a better way to fix this is to split up .gcc_except_table (D83655). I'll resurrect the patch.

I think a better way to fix this is to split up .gcc_except_table (D83655). I'll resurrect the patch.

I agree that splitting up gcc_except_table is the right approach. Glancing through the patch I am not sure how much work is involved there. Could we have this as a temporary fix until then guarded by a FIXME? This breaks way too many tests for us. Thanks.

I think a better way to fix this is to split up .gcc_except_table (D83655). I'll resurrect the patch.

I agree that splitting up gcc_except_table is the right approach. Glancing through the patch I am not sure how much work is involved there. Could we have this as a temporary fix until then guarded by a FIXME? This breaks way too many tests for us. Thanks.

Not much work is involved. D83655 is ready.

tmsriram abandoned this revision.Nov 5 2020, 5:40 PM

Abandoning it because D83655 fixes it by splitting up gcc_except_table.