On Fri, Mar 07, 2025 at 03:29:00PM -0800, H. Peter Anvin wrote: > On March 7, 2025 3:21:57 PM PST, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > >On Sat, Mar 08, 2025 at 12:05:29AM +0100, Ingo Molnar wrote: > >> > >> * H. Peter Anvin <hpa@xxxxxxxxx> wrote: > >> > >> > > #endif /* __ASSEMBLY__ */ > >> > > >> > So we are going to be using this version despite the gcc maintainers > >> > telling us it is not supported? > >> > >> No, neither patches are in the x86 tree at the moment. > > > >FWIW, the existing ASM_CALL_CONSTRAINT is also not supported, so this > >patch wouldn't have changed anything in that respect. > > > >Regardless I plan to post a new patch set soon with a bunch of cleanups. > > > >It will keep the existing ASM_CALL_CONSTRAINT in place for GCC, and will > >use the new __builtin_frame_address(0) input constraint for Clang only. > > > >There will be a new asm_call() interface to hide the mess. > > > > Alternatively, you can co-opt the gcc BR I already filed on this and > argue there that there are new reasons to support the alternate > construct. We hopefully won't need those hacks much longer anyway, as I'll have another series to propose removing frame pointers for x86-64. x86-32 can keep frame pointers, but doesn't need the constraints. It's not supported for livepatch so it doesn't need to be 100% reliable. Worst case, an unwind skips a frame, but the call address still shows up on stack trace dumps prepended with '?'. I plan to do the asm_call() series before the FP removal series because it's presumably less disruptive, and it has a bunch more orthogonal cleanups. -- Josh
|