[PATCH] D46874: [MC] - Add .stack_size sections into groups and link them with .text

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 23 07:02:53 PDT 2018


grimar added inline comments.


================
Comment at: test/CodeGen/X86/stack-size-section.ll:16
 ; CHECK-NEXT: .Lfunc_begin1:
 ; CHECK: .section .stack_sizes,"", at progbits
 ; CHECK-NEXT: .quad .Lfunc_begin1
----------------
grimar wrote:
> jhenderson wrote:
> > Should we still have SHF_LINK_ORDER in these cases? If we GC (or otherwise discard) the text section here, we'll still keep the stack_sizes section, which I don't think we want to do.
> > 
> > I know -gc-sections without -function-sections is rare, but it is legal, and LLD does potentially strip some sections (imagine an object file with only one or two unused functions in, for example).
> Ok. Problem is that currently ELF section key is based on section name, group and unique id:
> https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCContext.cpp#L393
> 
> Because of that the following code currently produce single .stack_sizes section:
> ```
> .section .text,"ax", at progbits
>  nop
> 
> .section .stack_sizes,"o", at progbits,.text
> .byte 1
> 
> .section .text,"ax", at progbits
>  nop
> 
> .section .stack_sizes,"o", at progbits,.text
> .byte 2
> ```
> 
> It would produce 2 if stack_sizes would have `unique` attribute set.
> 
> I can also imagine code when we have multiple .text sections without -ffunction-sections.
> Example:
> 
> ```
> int foo() {
>  return 0;
> }
> 
> int main () __attribute__ ((section (".text.main")));
> int main() {
>   return 0;
> }
> ```
> 
> In that case, we also would want to link .stack_sizes to its parent correctly. At the same time does not seem
> we really want to complicate the logic of finding the ideal unique ID for them right now. 
> (As -fno-function-sections case is rare and no need to optimize it that early probably) 
> 
> Given that I think the simple logic that should be OK for start would be to have `unique` property unconditionally set (for both -ffunction-sections and -fno-function-sections cases), like in one of the previous iterations. What do you think?
> 
My first sample is a bit confusing sorry. What I wanted to say is that without unique attribute it generates single .stack_sizes which is linked to nowhere. And to set sh_link field correctly, I think we need `unique` attribute now.


https://reviews.llvm.org/D46874





More information about the llvm-commits mailing list