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

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>

On Oct 17, 2013, at 7:24 PM, edA-qa mort-ora-y <eda-qa at disemia.com>
wrote:
> 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)
I forget, but it may be relevant. Try changing it and see if it helps.
> - the global variable is marked linkonce_odr unnamed_addr
> 
I don't think that that would affect anything. What's the ASM look like
between the JIT and the .s file?

-bw

On 18/10/13 05:47, Bill Wendling wrote:
>> - the clauses are always cast to i8* (I'm using an i64* as that is
my
>> type information)
> I forget, but it may be relevant. Try changing it and see if it helps.
I've tried this and it doesn't help. I also tried using a different type
(a structure type) for the types and it doesn't help.
>> - the global variable is marked linkonce_odr unnamed_addr
> I don't think that that would affect anything. What's the ASM look
like between the JIT and the .s file?
I'm not clear on what you wish me to compare. I have attached a small IR
program that shows how I am adding the clauses. I then just link with:

gcc -Wl,--eh-frame-hdr,--build-id -o exe object_a.o object_b.o object_c.o



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

@level1 = linkonce_odr unnamed_addr constant i64 1
@levelCatchAll = linkonce_odr unnamed_addr constant i64 0

declare i32 @leaf_exception_personality(i32, i32, i64, i8*, i8*)

declare i8* @count_malloc(i64)

declare void @count_free(i8*)

declare void @_void_destructor(i8*)

declare void @_duplicate_release_shared()

declare void @_uncaught_exception(i8*)

declare void @_raise_exception(i64)

declare void @_Unwind_Resume(i8*)

declare void @leaf_rethrow(i8*)

; Function Attrs: uwtable
define internal void @_entry() #0 {
entry:
  %_return_path = alloca i8
  store i8 0, i8* %_return_path
  %_exception = alloca { i8*, i32 }
  invoke void @test_throw()
          to label %post_call_4 unwind label %throw_land_2

func_ret_0:                                       ; preds = %seq_1
  ret void

seq_1:                                            ; preds = %post_call_4,
%throw_cont_3
  br label %func_ret_0

throw_land_2:                                     ; preds = %entry
  %0 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, i8*, i8*)*
@leaf_exception_personality
          catch i8* bitcast (i64* @level1 to i8*)
  store { i8*, i32 } %0, { i8*, i32 }* %_exception
  br label %throw_cont_3

throw_cont_3:                                     ; preds = %throw_land_2
  store i8 0, i8* %_return_path
  call void @trace_integer(i64 1)
  br label %seq_1

post_call_4:                                      ; preds = %entry
  br label %seq_1
}

declare void @trace_integer(i64)

declare void @test_throw()

; Function Attrs: uwtable
define i64 @main() #0 {
entry:
  invoke void @_entry()
          to label %end_1 unwind label %catch_0

catch_0:                                          ; preds = %entry
  %0 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, i8*, i8*)*
@leaf_exception_personality
          catch i8* bitcast (i64* @levelCatchAll to i8*)
  %1 = extractvalue { i8*, i32 } %0, 0
  call void @_uncaught_exception(i8* %1)
  ret i64 255

end_1:                                            ; preds = %entry
  ret i64 0
}

attributes #0 = { uwtable }
-------------- 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/27b37719/attachment.sig>