Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootstrap failure "Error: can not do 8 byte pc-relative relocation" #5376

Closed
pwo opened this issue Sep 18, 2009 · 74 comments
Closed

Bootstrap failure "Error: can not do 8 byte pc-relative relocation" #5376

pwo opened this issue Sep 18, 2009 · 74 comments

Comments

@pwo
Copy link

@pwo pwo commented Sep 18, 2009

Bugzilla Link 5004
Resolution FIXED
Resolved on Feb 15, 2010 18:58
Version trunk
OS FreeBSD
Blocks #4068
CC @asl,@lattner,@davidchisnall,@echristo,@tlattner

Extended Description

Using llvm r82173 and gcc 4.2.1 20070719 as the host compiler the bootstrap of llvm-gcc r82176 fails to bootstrap on FreeBSD/amd64 8.0

/usr/src-local/llvm-gcc/obj/./gcc/xgcc -shared-libgcc -B/usr/src-local/llvm-gcc/obj/./gcc -nostdinc++ -L/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/src -L/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/src/.libs -B/opt/llvm-gcc/x86_64-unknown-freebsd8.0/bin/ -B/opt/llvm-gcc/x86_64-unknown-freebsd8.0/lib/ -isystem /opt/llvm-gcc/x86_64-unknown-freebsd8.0/include -isystem /opt/llvm-gcc/x86_64-unknown-freebsd8.0/sys-include -I/usr/src-local/llvm-gcc/libstdc++-v3/../gcc -I/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/include/x86_64-unknown-freebsd8.0 -I/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/include -I/usr/src-local/llvm-gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c ../../../../libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o
/var/tmp//ccEBSLfL.s: Assembler messages:
/var/tmp//ccEBSLfL.s:757: Error: can not do 8 byte pc-relative relocation
/var/tmp//ccEBSLfL.s:772: Error: can not do 8 byte pc-relative relocation
/var/tmp//ccEBSLfL.s:793: Error: can not do 8 byte pc-relative relocation
gmake[4]: *** [eh_alloc.lo] Error 1
gmake[4]: Leaving directory `/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/libsupc++'

@pwo
Copy link
Author

@pwo pwo commented Sep 18, 2009

assigned to @asl

@asl
Copy link
Collaborator

@asl asl commented Sep 18, 2009

Please attach the LLVM IR. I doubt anyone who can look ino the problem has FreeBSD around.

@lattner
Copy link
Collaborator

@lattner lattner commented Sep 18, 2009

Please attach both the LLVM IR and the .s file, thanks.

@pwo
Copy link
Author

@pwo pwo commented Sep 20, 2009

@pwo
Copy link
Author

@pwo pwo commented Sep 20, 2009

@pwo
Copy link
Author

@pwo pwo commented Sep 20, 2009

This bug is now also seen with the 2.6-PRE2 release, PRE1 did not have this problem.

I've attached both the assembly and LLVM IR.

@tlattner
Copy link
Contributor

@tlattner tlattner commented Sep 22, 2009

This is a 2.6 release blocker. Is someone working on it or do we need to recruit more people?

@lattner
Copy link
Collaborator

@lattner lattner commented Sep 22, 2009

Pawel, please include the output of running 'gcc -c eh_alloc.s' on the .s file. The line numbers above don't line up.

@lattner
Copy link
Collaborator

@lattner lattner commented Sep 22, 2009

Actually, running 'gcc -m64 eh_alloc.s -c' on a linux system assembled the file just fine. Are you sure there is a problem here?

@tlattner
Copy link
Contributor

@tlattner tlattner commented Sep 23, 2009

Pawel - Any updates?

@pwo
Copy link
Author

@pwo pwo commented Sep 23, 2009

Expect an update within two hours, I'm updating my trunk build of llvm now.
The IR and ASM was the output from 2.6, sorry for not attaching the output, this was the reason the lines probably didn't line up.

@pwo
Copy link
Author

@pwo pwo commented Sep 24, 2009

gcc -c eh_alloc.s

eh_alloc.s: Assembler messages:
eh_alloc.s:774: Error: can not do 8 byte pc-relative relocation
eh_alloc.s:789: Error: can not do 8 byte pc-relative relocation

binutils is 2.15

Build output from trunk:
/usr/src-local/llvm-gcc/obj/./gcc/xgcc -shared-libgcc -B/usr/src-local/llvm-gcc/obj/./gcc -nostdinc++ -L/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/src -L/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/src/.libs -B/opt/llvm-gcc/x86_64-unknown-freebsd8.0/bin/ -B/opt/llvm-gcc/x86_64-unknown-freebsd8.0/lib/ -isystem /opt/llvm-gcc/x86_64-unknown-freebsd8.0/include -isystem /opt/llvm-gcc/x86_64-unknown-freebsd8.0/sys-include -I/usr/src-local/llvm-gcc/libstdc++-v3/../gcc -I/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/include/x86_64-unknown-freebsd8.0 -I/usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/include -I/usr/src-local/llvm-gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c ../../../../libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o
/var/tmp//ccM0T20x.s: Assembler messages:
/var/tmp//ccM0T20x.s:774: Error: can not do 8 byte pc-relative relocation
/var/tmp//ccM0T20x.s:789: Error: can not do 8 byte pc-relative relocation
gmake[4]: *** [eh_alloc.lo] Error 1
gmake[4]: Leaving directory /usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3/libsupc++' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory /usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory /usr/src-local/llvm-gcc/obj/x86_64-unknown-freebsd8.0/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory /usr/src-local/llvm-gcc/obj'
gmake: *** [bootstrap] Error 2

@pwo
Copy link
Author

@pwo pwo commented Sep 24, 2009

@pwo
Copy link
Author

@pwo pwo commented Sep 24, 2009

@lattner
Copy link
Collaborator

@lattner lattner commented Sep 24, 2009

It looks like freebsd (or that version of gas) doesn't support that relocation type. This code seems to be to blame in DwarfException.cpp:

// If there is a personality and landing pads then point to the language
// specific data area in the exception table.
if (MMI->getPersonalities()[0] != NULL) {
  bool is4Byte = TD->getPointerSize() == sizeof(int32_t);

  Asm->EmitULEB128Bytes(is4Byte ? 4 : 8);
  Asm->EOL("Augmentation size");

  if (EHFrameInfo.hasLandingPads)
    EmitReference("exception", EHFrameInfo.Number, true, false);

Pawel, if you force "is4Byte" to true, does it work for you?

@pwo
Copy link
Author

@pwo pwo commented Sep 24, 2009

@pwo
Copy link
Author

@pwo pwo commented Sep 24, 2009

@pwo
Copy link
Author

@pwo pwo commented Sep 25, 2009

I should have said that the last two attachments are from 2.6-PRE1 that builds ok.

@asl
Copy link
Collaborator

@asl asl commented Oct 11, 2009

This is generic problem in our dwarf asmprinting, which seems currently to be pretty darwin-centric.

The problem is that we're emitting pcrel reference to EH frame. This is ok only for darwin. For linux we should use absptr / udata4 depending on the codemodel. 8 byte pcrel relocations should be used only for large / kernel code models (and in PIC mode only). This is actually both optimization & correctness stuff.

Optimization: the section is placed at zero address, thus pcrel relocations are generally not neeeded. Also they are quite big...
Correctness: 8 byte pcrel relocations were added only in binutils 2.17

The deleted EHFreferredDataFormat hooks returned proper encoding in all the cases. We need to restore them and implement generic reference printing routine (for given encoding).

@asl
Copy link
Collaborator

@asl asl commented Oct 11, 2009

Proposed solution:

  1. Implement MAI hooks for returning target-specific personality / fde / lsda encodings
  2. Extend EmitReference stuff to work with encodings, not with bunch of flags (indirect / force32 bit)
  3. Use encodings consistently across the code (currently we're emitting encodings & handle reference printing separately effectively duplicating the stuff)

Estimated time to implement: 2-4 hours
Pros: Obvious
Cons: need extra round of tests :(

@asl
Copy link
Collaborator

@asl asl commented Oct 11, 2009

Proposed solution:

  1. Implement MAI hooks for returning target-specific personality / fde / lsda
    encodings
    Actually, we need to think about proper way, since encoding (at least on linux) depends on relocation model & code model. This should not be exposed via MAI

@lattner
Copy link
Collaborator

@lattner lattner commented Oct 11, 2009

Ok, this is no longer blocking 2.6. This is going to require some invasive surgery and needs to be baked. For 2.6 we should recommend that people upgrade their binutils if they run into this. I'll update the release notes to mention it.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 2, 2009

llvm-gcc also has this problem on OpenBSD/amd64 for what it's worth. Currently an older version of binutils (2.15) is used which doesn't have R_X86_64_SIZE64.

There are plans to update binutils but this is a lot of work to catch breakage
on all the supported platforms and fix it.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Dec 7, 2009

recently I started seeing this with clang++:

pes ~$ cat catch.cc
void bar(void);
void foo(void) {
try {
bar();
}
catch (...) {
}
}
pes ~$ clang++ catch.cc
/tmp/cc-wXOL0W.s: Assembler messages:
/tmp/cc-wXOL0W.s:138: Error: can not do 8 byte pc-relative relocation
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
pes ~$

is it the same issue as described here? if so is there any progress with this? (this is blocking llvm compilation with clang for example)

@asl
Copy link
Collaborator

@asl asl commented Jan 8, 2010

*** Bug llvm/llvm-bugzilla-archive#5977 has been marked as a duplicate of this bug. ***

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Jan 29, 2010

@asl
Copy link
Collaborator

@asl asl commented Jan 30, 2010

Preliminary patch
Here is preliminary patch to try. It implements:

  • Hooks to return Personality / FDE / LSDA / TType encoding depending on target / options (e.g. code model / relocation model)
  • MCIzation of Dwarf EH printer to use encoding information
  • Stub generation for ELF target (needed for indirect references)
  • Some other small changes here and there

Tested on x86-32 and x86-64 linux. Not tested on darwin.

@pwo
Copy link
Author

@pwo pwo commented Jan 30, 2010

The patch looks pretty good, llvm-gcc bootstraps (c,c++), a lot of previously broken c++ apps in FreeBSD now build. clang self-builds to the point of a link failure.

@davidchisnall
Copy link
Contributor

@davidchisnall davidchisnall commented Jan 30, 2010

Created an attachment (id=4141) [details]
Preliminary patch

This patch is close:

$ cat picfail.m
#import <objc/Object.h>
#import <objc/NXConstStr.h>

int main(void)
{
@Try {
@throw(@"foo");
}
@catch(Object *a) {}
return 0;
}
$ clang -fPIC picfail.m
/tmp/cc-Qugv3L.s: Assembler messages:
/tmp/cc-Qugv3L.s:311: Error: symbol `.L__unnamed_1' is already defined
clang: error: assembler command failed with exit code 1 (use -v to see invocation)

The EH data seems correct, the address is now:

.long   .L__unnamed_1-.

This is what gcc emits, while clang previously generated this:

.long    .L__unnamed_1

(Where .L__unnamed_1 is "Object")

However, at the end of the file I find this:

.section    .note.GNU-stack,"",@progbits
.section    .data.rel,"aw",@progbits

.L__gnu_objc_personality_v0:
.long __gnu_objc_personality_v0
.L__unnamed_1:
.long .L__unnamed_1

This second definition of .L__unnamed_1 is breaking things.

The reference to the personality function also looks very different. This appears to be a regression; the unwind library was correctly finding the personality function with the old version, now it is failing to. There seem to be a number of changes to the EH frame. Before the change:

.byte   0x1B
.long   __gnu_objc_personality_v0-.

After:

.byte   155
.long   .L__gnu_objc_personality_v0-.

It's a bit difficult to play spot the difference because you've made it emit decimal, rather than hex, values for the constants, however, note that the value of the byte immediately preceding the address of the personality function changed from 27 to 155 as a result of this patch. I'm not sure what this change means - I can't find the ABI docs - but reverting this in the generated assembly cause it to enter the personality routine. Unfortunately, it still crashes in the part of the personality function that tries to read .L__unnamed_1.

The rest of the exception frame looks totally different in GCC. I can provide you with the assembled versions of both if you like, or you can generate them by compiling the trivial example from above with gcc and clang.

@asl
Copy link
Collaborator

@asl asl commented Jan 30, 2010

This second definition of .L__unnamed_1 is breaking things.
Ok, this makes sense. Stub generation should be improved to honour private symbols properly.

changed from 27 to 155 as a result of this patch. I'm not sure what this
change means - I can't find the ABI docs
That's correct change. We need to use indirect pcrel encoding in general.

The rest of the exception frame looks totally different in GCC.
This is surely expected.

@asl
Copy link
Collaborator

@asl asl commented Feb 10, 2010

I'm confused. Where do you see it requiring codegen?
Yeah, sorry, I looked into wrong line.

@asl
Copy link
Collaborator

@asl asl commented Feb 10, 2010

You need to figure out a different way of doing this:
Basically, we need to figure out how to resolve this layering violation. It's funny why this problem didn't trigger before - the only reason is that stub emission code is broken on non-x86 darwin (e.g. ppc),
It pretends to emit stub, but doesn't do this, all necessary code is moved to X86MachoTargetObjectLowering, otherwise (if implemented correctly) we'd have macho MMI use inside this file as well...

@asl
Copy link
Collaborator

@asl asl commented Feb 10, 2010

Updated patch with layering problems fixes
Bill, please try this file, it should have all layering problems fixed.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 10, 2010

Created an attachment (id=4209) [details]
Updated patch with layering problems fixes

Bill, please try this file, it should have all layering problems fixed.

Thanks. That compiled. I did get an error in this test case, though:

CodeGen/Generic/2007-05-05-Personality.ll -mtriple=i686-pc-linux-gnu

It turns out that the CIE augmentation is this:

.asciz "zPL" # CIE Augmentation

It's expecting it to be "zPLR".

@asl
Copy link
Collaborator

@asl asl commented Feb 10, 2010

It's expecting it to be "zPLR".
"R" means that we're using non-default (non-absptr) FDE encoding. For x86-32/linux in non-PIC mode we're using absptr FDEs, so, the output is correct, I'll check the test twice & fix it.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

It's expecting it to be "zPLR".
"R" means that we're using non-default (non-absptr) FDE encoding. For
x86-32/linux in non-PIC mode we're using absptr FDEs, so, the output is
correct, I'll check the test twice & fix it.

Could you run the llvm-gcc "check-g++" testsuite on this first? If that passes, then you can go ahead and submit the patch with the change to the test mentioned above.

Thanks!

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

Oops! Spoke too soon. There were a large number of new failures with this patch in the g++ testsuite. I'm attaching the "new.g++.sum", which is run with your patch, against TOT ("old.g++.sum").

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

Could you run the llvm-gcc "check-g++" testsuite on this first? If that passes,
then you can go ahead and submit the patch with the change to the test
mentioned above.
I did this, it passed. Duncan also tested it on Ada ACATS, which uses EH alot.

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

Oops! Spoke too soon. There were a large number of new failures with this patch
in the g++ testsuite. I'm attaching the "new.g++.sum", which is run with your
patch, against TOT ("old.g++.sum").
-ENOATTACH :)

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

-ENOATTACH :)

Sorry. Attached. :-)

I hope that it was just me running the test incorrectly. How did you run it?

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

-ENOATTACH :)

Sorry. Attached. :-)
Just to make sure - where did you run the testsuite? On SL?

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

I hope that it was just me running the test incorrectly. How did you run it?
Ok, it turned out to be a silly typo for x86-64 darwin, which leads to assertion you're seeing during test run.

I didn't run the test on darwin - I just compared several assembler outputs to make sure that nothing changed insanely.

Updated patch attached.

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

Ok, it turned out to be a silly typo for x86-64 darwin, which leads to
assertion you're seeing during test run.

I didn't run the test on darwin - I just compared several assembler outputs to
make sure that nothing changed insanely.

Updated patch attached.

Thanks! I'll test this out.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 12, 2010

Updated patch attached.

There were 10 regressions in the check-g++. I added the pr5004-4.sum file as an attachment.

@asl
Copy link
Collaborator

@asl asl commented Feb 12, 2010

Updated patch attached.

There were 10 regressions in the check-g++. I added the pr5004-4.sum file as an
attachment.
Thanks! I'll investigate

@asl
Copy link
Collaborator

@asl asl commented Feb 13, 2010

Updated patch, try 5
Ok, yet another try with one more typo fixed :)

I verified - cp_compat now works :)

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 15, 2010

Created an attachment (id=4223) [details]
Updated patch, try 5

Ok, yet another try with one more typo fixed :)

I verified - cp_compat now works :)

It looks good. The only problem I saw was with the "FAIL: g++.dg/eh/cleanup1.C" test. But I've been noticing that it's been compiling really slowly lately. Like, on the order of 36 minutes. So it's basically timing out.

It seems to happen in the front end before it gets to the EH stuff in the llvm-convert.cpp file. I don't have an explanation for it.

I'm going to say that your last patch works for Darwin. Thanks! :-)

@asl
Copy link
Collaborator

@asl asl commented Feb 15, 2010

Created an attachment (id=4223) [details] [details]
Updated patch, try 5

Ok, yet another try with one more typo fixed :)

I verified - cp_compat now works :)

It looks good. The only problem I saw was with the "FAIL: g++.dg/eh/cleanup1.C"
cleanup1 is nasty - it contains 'just' 4000 cleanups, so, yes, it will definitely time out.

I'm going to say that your last patch works for Darwin. Thanks! :-)
Awesome! I'll apply it then.

@echristo
Copy link
Contributor

@echristo echristo commented Feb 15, 2010

... It wasn't timing out last time I worked on it. What happened?

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 15, 2010

... It wasn't timing out last time I worked on it. What happened?

I'm stumped myself. It's not timing out all of the time. And I even have a build which doesn't time out. Maybe it's a "debug" verses "release" build thing?

@asl
Copy link
Collaborator

@asl asl commented Feb 16, 2010

I'm stumped myself. It's not timing out all of the time. And I even have a
build which doesn't time out. Maybe it's a "debug" verses "release" build
thing?
debug also timeouts for me, release - not

@asl
Copy link
Collaborator

@asl asl commented Feb 16, 2010

So... finally fixed in commit series r96285-96290

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 16, 2010

Could you apply the patch from
http://llvm.org/bugs/attachment.cgi?id=4136
as well ?

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Feb 16, 2010

Could you apply the patch from
http://llvm.org/bugs/attachment.cgi?id=4136
as well ?

Done:

Sending lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp
Transmitting file data .
Committed revision 96304.

@asl
Copy link
Collaborator

@asl asl commented Nov 27, 2021

mentioned in issue llvm/llvm-bugzilla-archive#5977

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants