assigned to @asl

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

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

eh_alloc.bc

eh_alloc.s

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.

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

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

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?

Pawel - Any updates?

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.

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

eh_alloc.bc from trunk

eh_alloc.s from trunk

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?

eh_alloc.bc from 2.6

eh_alloc.s from 2.6

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

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).

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 :(

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

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.

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.

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)

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

patch to fix LSDA encoding in the CIE generated by the LLVM JIT.

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.

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.

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.

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.

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

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...

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

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".

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.

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!

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").

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.

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 :)

check-g++ run with the updated patch.

check-g++ run without thepatch.

-ENOATTACH :)

Sorry. Attached. :-)

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

-ENOATTACH :)

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

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.

Updated patrch with darwin fixes

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.

Check-g++ run with pr5004-4 patch

Updated patch attached.

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

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

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

I verified - cp_compat now works :)

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! :-)

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.

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

... 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?

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

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

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

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.

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