[lkml]   [2019]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 02/17] x86, lto: Mark all top level asm statements as .text
> Well, we better should know the real reason for this wreckage. I mean, the
> default section for text is suprisingly .text. I don't see a reason why
> this would be any different for an assembly function implemented in a C
> file.

What happens is that when the function before the asm changes
the section, gcc only changes it back for the next function/variable
with a different section. But it doesn't change it back for the asm.

e.g. here

__attribute__((section("foo"))) void func(void)


gives with gcc -S (might be different with optimization):

.section foo,"ax",@progbits <----------------- sets the section
.globl func
.type func, @function
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
popq %rbp
.cfi_def_cfa 7, 8
.size func, .-func
<--------------------------- no section reset before the asm

.ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)"
.section .note.GNU-stack,"",@progbits

> So the question is whether GCC does something silly in general which gets
> 'repaired' silentely by the linker or whether it's just an LTO issue.

The linker has no idea about the boundaries between functions and toplevel
asms. So if gcc doesn't reset the section they stay in the same.

My LTO build was just unlucky I think because it ended up with
asm next to initcall function, which is likely not common.

But gcc reorders functions even without LTO inside files,
so it could eventually happen.

> If it's the former, then we must backport those fixes.
> Could you please verify with the GCC people as you seem to have a
> reproducer of some sort.

Okay. I filed

I thought I had already done that, but it seems I didn't.


 \ /
  Last update: 2019-03-27 01:56    [W:0.082 / U:31.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site