Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 18 Jul 2022 15:34:51 -0700 | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
On Mon, Jul 18, 2022 at 2:43 PM Peter Zijlstra <peterz@infradead.org> wrote: > > FWIW, when I was poking at this last week, I found that -falign-function > only seems to apply to the normal .text section and not to random other > sections with text we create. > > Or rather, I was seeind a lot of unaligned functions that all had custom > sections despite explicitly using the (what I thought was a global) > function alignment toggle.
Hmm. This triggers a memory..
I think we may have two different issues at play.
One is that I think our linker script only aligns code sections to 8 bytes by default. Grep for ALIGN_FUNCTION.
And I think that any .align directive (or .p2align) only aligns relative to that section, so if the section itself wasn't aligned, it doesn't help to have some alignment within the section.
I may be wrong.
But I can definitely see gcc not aligning functions too, and doing a
nm vmlinux | grep ' t ' | grep -v '0 t ' | grep -v '\.cold$' | sort
shows a _lot_ of them for me.
I think the main cause is that the ACPI code builds with
ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
and that '-Os' will disable all function alignment. I think there's a few other places that do that too.
I don't see the same effect in my clang build, so I think that -Os behavior is likely gcc-specific.
In my clang build, I do see a few unaligned function symbols, but they seem to be all our own assembler ones (eg "nested_nmi") and they seem to be intentional (ie that "nested_nmi" thing is in the middle of the "asm_exc_nmi" function, which is the real thing and which _is_ aligned).
Linus
| |