thr3ads.net - llvm dev - [LLVMdev] gcroot + `section not found for addresss ...' ??? [Apr 2011]

If this information is useful, please help other people find it:
Share via:

Bill Wendling

2011-Apr-12 00:07 UTC

[LLVMdev] gcroot + `section not found for addresss ...' ???

This is an interesting problem. The GC code is being converted into
'invokes' instead of calls:

define i32 @main() gc "shadow-stack" {
entry:
  %gc_frame = alloca %gc_stackentry.main
  %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain
  %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0,
i32 1
  store %gc_map* getelementptr inbounds (%gc_map.0* @__gc_main, i32 0, i32 0),
%gc_map** %gc_frame.map
  %0 = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 1
  store i8* null, i8** %0
  %gc_frame.next = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0,
i32 0
  %gc_newhead = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0
  store %gc_stackentry* %gc_currhead, %gc_stackentry** %gc_frame.next
  store %gc_stackentry* %gc_newhead, %gc_stackentry** @llvm_gc_root_chain
  %1 = invoke i8* @malloc(i64 1)
          to label %entry.cont unwind label %gc_cleanup

entry.cont:                                       ; preds = %entry
  store i8* %1, i8** %0
  %gc_frame.next1 = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0,
i32 0
  %gc_savedhead = load %gc_stackentry** %gc_frame.next1
  store %gc_stackentry* %gc_savedhead, %gc_stackentry** @llvm_gc_root_chain
  ret i32 0

gc_cleanup:                                       ; preds = %entry
  %gc_frame.next2 = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0,
i32 0
  %gc_savedhead3 = load %gc_stackentry** %gc_frame.next2
  store %gc_stackentry* %gc_savedhead3, %gc_stackentry** @llvm_gc_root_chain
  unwind
}

However, there isn't a personality function associated here. This conflicts
with the fact that there's an LSDA associated with the function. It's
not really feasible that there would be an LSDA but no personality function.
Also note that the landing pad of the 'invoke' doesn't include any
of the exception handling intrinsics. During the DwarfEHPrepare pass, an
@llvm.eh.exception() call is added (thus marking that as a "landing
pad" in code-gen), but there isn't an equivalent @llvm.eh.selector
call.

I don't know enough about GC stuff to say what should happen here. Though it
looks like we at least need the gc_cleanup to generate an llvm.eh.selector call
at the very least...The question becomes which personality function it should
call, because that's language-specific.

-bw

On Apr 11, 2011, at 9:42 AM, Nick Kledzik wrote:
> The linker is going off in the weeds trying to parse the dwarf unwind info.
The CIE has:
> 
> 
> Leh_frame_common_begin0:
> 	.long	0                       ## CIE Identifier Tag
> 	.byte	1                       ## DW_CIE_VERSION
> 	.asciz	 "zLR"                  ## CIE Augmentation
> 	.byte	1                       ## CIE Code Alignment Factor
> 	.byte	120                     ## CIE Data Alignment Factor
> 	.byte	16                      ## CIE Return Address Column
> 	.byte	2                       ## Augmentation Size
> 	.byte	16                      ## LSDA Encoding = pcrel
> 	.byte	16                      ## FDE Encoding = pcrel
> 
> 
> But the FDE has:
> 
> 	.byte	 0                       ## Augmentation size
> 
> The linker is expecting that since the CIE said there was an LSDA in each
FDE that is pcrel encoded, that there would in fact be an LSDA in each FDE.  But
in this case, the compiler is trying to omit the LSDA by marking that the FDE
has a zero sized augmentation data.
> 
> I'll have to research if this is a valid dwarf unwind optimization. 
Even if it is, it is tripping up the existing linker.
> 
> -Nick
> 
> 
> On Apr 10, 2011, at 6:06 AM, Nicolas Ojeda Bar wrote:
>> Hi,
>> 
>> If I type
>> 
>> define i32 @main() gc "shadow-stack" {
>> entry:
>> %0 = alloca i8*
>> %1 = call i8* @malloc(i64 1)
>> store i8* %1, i8** %0
>> call void @llvm.gcroot(i8** %0, i8* null)
>> ret i32 0
>> }
>> 
>> declare i8* @malloc(i64)
>> 
>> declare void @llvm.gcroot(i8**, i8*) nounwind
>> 
>> in test.ll
>> 
>> and then do
>> 
>>> llc test.ll
>>> gcc test.s
>> 
>> I get the error
>> 
>> ld: in /var/folders/Ea/EakEx6b+GBSo6cUn2AnFZk+++TI/-Tmp-//cc5d3RCx.o,
section not found for address 0x64200E00000004CD
>> 
>> If I remove line containing malloc and the line after that, no such
error happens. If I remove
>> the gcroot line then no such error happens.
>> 
>> Any hints as to what this error means would be great!
>> 
>> Cheers,
>> N
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Duncan Sands

2011-Apr-12 06:27 UTC

head link

[LLVMdev] gcroot + `section not found for addresss ...' ???

Hi Bill,
> However, there isn't a personality function associated here. This
conflicts with the fact that there's an LSDA associated with the function.
It's not really feasible that there would be an LSDA but no personality
function.
GCC recently added support for this, i.e. a situation in which there are only
cleanups to be run: it uses the C personality function even if the language
being compiled is not C.
> I don't know enough about GC stuff to say what should happen here.
Though it looks like we at least need the gc_cleanup to generate an
llvm.eh.selector call at the very least...The question becomes which personality
function it should call, because that's language-specific.
One reason I added lowering for "unwind" in DwarfEHPrepare was to help
handle
this situation: an invoke followed by some cleanup code followed by unwind.  I
had GC lowering in mind.  I think the only thing missing is having the code
generators use the C personality function by default if there is no personality
function, but as I didn't work on this for a while I don't recall
exactly how
far I got.

Ciao, Duncan.

>
> -bw
>
> On Apr 11, 2011, at 9:42 AM, Nick Kledzik wrote:
>
>> The linker is going off in the weeds trying to parse the dwarf unwind
info.   The CIE has:
>>
>>
>> Leh_frame_common_begin0:
>> 	.long	0                       ## CIE Identifier Tag
>> 	.byte	1                       ## DW_CIE_VERSION
>> 	.asciz	 "zLR"                  ## CIE Augmentation
>> 	.byte	1                       ## CIE Code Alignment Factor
>> 	.byte	120                     ## CIE Data Alignment Factor
>> 	.byte	16                      ## CIE Return Address Column
>> 	.byte	2                       ## Augmentation Size
>> 	.byte	16                      ## LSDA Encoding = pcrel
>> 	.byte	16                      ## FDE Encoding = pcrel
>>
>>
>> But the FDE has:
>>
>> 	.byte	 0                       ## Augmentation size
>>
>> The linker is expecting that since the CIE said there was an LSDA in
each FDE that is pcrel encoded, that there would in fact be an LSDA in each FDE.
But in this case, the compiler is trying to omit the LSDA by marking that the
FDE has a zero sized augmentation data.
>>
>> I'll have to research if this is a valid dwarf unwind optimization.
Even if it is, it is tripping up the existing linker.
>>
>> -Nick
>>
>>
>> On Apr 10, 2011, at 6:06 AM, Nicolas Ojeda Bar wrote:
>>> Hi,
>>>
>>> If I type
>>>
>>> define i32 @main() gc "shadow-stack" {
>>> entry:
>>> %0 = alloca i8*
>>> %1 = call i8* @malloc(i64 1)
>>> store i8* %1, i8** %0
>>> call void @llvm.gcroot(i8** %0, i8* null)
>>> ret i32 0
>>> }
>>>
>>> declare i8* @malloc(i64)
>>>
>>> declare void @llvm.gcroot(i8**, i8*) nounwind
>>>
>>> in test.ll
>>>
>>> and then do
>>>
>>>> llc test.ll
>>>> gcc test.s
>>>
>>> I get the error
>>>
>>> ld: in
/var/folders/Ea/EakEx6b+GBSo6cUn2AnFZk+++TI/-Tmp-//cc5d3RCx.o, section not found
for address 0x64200E00000004CD
>>>
>>> If I remove line containing malloc and the line after that, no such
error happens. If I remove
>>> the gcroot line then no such error happens.
>>>
>>> Any hints as to what this error means would be great!
>>>
>>> Cheers,
>>> N
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Bill Wendling

2011-Apr-12 07:55 UTC

head link

[LLVMdev] gcroot + `section not found for addresss ...' ???

On Apr 11, 2011, at 11:27 PM, Duncan Sands wrote:
> Hi Bill,
> 
>> However, there isn't a personality function associated here. This
conflicts with the fact that there's an LSDA associated with the function.
It's not really feasible that there would be an LSDA but no personality
function.
> 
> GCC recently added support for this, i.e. a situation in which there are
only
> cleanups to be run: it uses the C personality function even if the language
> being compiled is not C.
> 
>> I don't know enough about GC stuff to say what should happen here.
Though it looks like we at least need the gc_cleanup to generate an
llvm.eh.selector call at the very least...The question becomes which personality
function it should call, because that's language-specific.
> 
> One reason I added lowering for "unwind" in DwarfEHPrepare was to
help handle
> this situation: an invoke followed by some cleanup code followed by unwind.
I
> had GC lowering in mind.  I think the only thing missing is having the code
> generators use the C personality function by default if there is no
personality
> function, but as I didn't work on this for a while I don't recall
exactly how
> far I got.
> Hi Duncan,

If it's a matter of defaulting to the C personality function, then that
should be a fairly easy change to make. I'll look into it, though it may
take a backseat to other things that I have to do right now unless someone else
wants to.

Nicolas,

Could you file a PR for this?

-bw

Seemingly Similar Threads

Search for more seemingly similar threads

llvm dev - Apr 2011 - [LLVMdev] gcroot + `section not found for addresss ...' ???

[LLVMdev] gcroot + `section not found for addresss ...' ???

[LLVMdev] gcroot + `section not found for addresss ...' ???

[LLVMdev] gcroot + `section not found for addresss ...' ???

Seemingly Similar Threads