llvm dev - Oct 2013 - [LLVMdev] post-link Dwarf information appears wrong, works in JIT

I'm working on exception handling and having some trouble with type
information. My personality/types work fine when running in the JIT, but
when I produce object files and link them it fails.

In particular, from an action record and the LSDA I get a type table
entry. The problem is this doesn't appear to be pointing to a valid
location. If I derefence it a segfault occurs.

Are there perhaps some linker flags that I must use to get this working
correctly?


-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131017/4d568ea4/attachment.sig>

On Oct 17, 2013, at 11:35 AM, edA-qa mort-ora-y <eda-qa at disemia.com>
wrote:
> I'm working on exception handling and having some trouble with type
> information. My personality/types work fine when running in the JIT, but
> when I produce object files and link them it fails.
> 
> In particular, from an action record and the LSDA I get a type table
> entry. The problem is this doesn't appear to be pointing to a valid
> location. If I derefence it a segfault occurs.
> 
> Are there perhaps some linker flags that I must use to get this working
> correctly?
> 
There shouldn't be any special linker flags you need to use. If you're
getting segfaults, it's probably trying to access the data at an invalid
location or something. Make sure that your EH table is properly aligned. You
might want to hand calculate the values to make sure that they're correct.
What platform are you using?

-bw

On 17/10/13 23:57, Bill Wendling wrote:
> There shouldn't be any special linker flags you need to use. If
> you're getting segfaults, it's probably trying to access the data
at
> an invalid location or something. Make sure that your EH table is
> properly aligned. You might want to hand calculate the values to make
> sure that they're correct. What platform are you using?
I don't know that I do anything to alter the alignment: I'm just using
the "addClause" function of the landingpad. Platform is x86_64 on
Linux.
Note that in the JIT my code does work, so my assumption is that I
haven't done something completely wrong, just partially wrong.

I'm looking at code generated by clang from C++, and I notice a few
differences. Are these relevant?
- the clauses are always cast to i8* (I'm using an i64* as that is my
type information)
- the global variable is marked linkonce_odr unnamed_addr


-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/c711ad23/attachment.sig>

I added several more clauses to see the result. It looks like the
landing pad information is generated correctly: I get the correct number
of action records, each record has a reasonable index into the type
table (from 1 to 9). The encoded address increment in 4 however, which
is unexpected since they are size 8 (in the JIT they increment by 8).
Whatever is causing that may also be responsible for the type table
address being incorrect.

It's the same IR code, so I presume there's something wrong with the
linking via gcc.

On 17/10/13 20:35, edA-qa mort-ora-y wrote:
> I'm working on exception handling and having some trouble with type
> information. My personality/types work fine when running in the JIT, but
> when I produce object files and link them it fails.
> 
> In particular, from an action record and the LSDA I get a type table
> entry. The problem is this doesn't appear to be pointing to a valid
> location. If I derefence it a segfault occurs.
> 
> Are there perhaps some linker flags that I must use to get this working
> correctly?
-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/65af908b/attachment.sig>

On Oct 17, 2013, at 9:37 PM, edA-qa mort-ora-y <eda-qa at disemia.com>
wrote:
> I added several more clauses to see the result. It looks like the
> landing pad information is generated correctly: I get the correct number
> of action records, each record has a reasonable index into the type
> table (from 1 to 9). The encoded address increment in 4 however, which
> is unexpected since they are size 8 (in the JIT they increment by 8).
> Whatever is causing that may also be responsible for the type table
> address being incorrect.
> 
> It's the same IR code, so I presume there's something wrong with
the
> linking via gcc.
> 
I'm dubious that it's a linking problem. These are in their own section
and should be aligned correctly. You might be reduced to stepping through the
unwinding library with your debugger (I have battle stories about doing that).
You can find out what the personality function is really reading and if it's
unaligned or just garbage data or something...

-bw