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

[George Rimar via Phabricator via llvm-commits]

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



https://reviews.llvm.org/D46874