https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117311

            Bug ID: 117311
           Summary: Documentation request: __builtin_frame_address(0) and
                    inline assembly
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com
  Target Milestone: ---

This is strictly a documentation request, as experimentation seems to indicate
that this construct already works as intended.

In the Linux kernel, we have cases where inline assembly may need to do a
"call", usually(*) due to being a fallback case to an out-of-line handler
during inline code patching.

When compiling with frame pointers, this means we need the frame pointer set up
before this instruction.

Right now, we use the construct:

register unsigned long current_stack_pointer asm("%rsp");
#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)

... which has several problems:

1. It is at the very best obscure, and doesn't seem like it would actually
convey to the compiler what the programmer is actually looking for here.
2. It uses an inout constraint, which on older versions of gcc was incompatible
with "asm goto".
3. It is at least partially x86-specific.

Experimentation seems to indicate that the following *input* constraints seem
to have the same effect, without the above problems:

#define ASM_CALL_CONSTRAINT "r" (__builtin_frame_address(0))

In all cases I have been able to construct, gcc (and clang) will ensure that
the frame pointer is set up before the asm (even if compiling with
-fomit-frame-pointer) and the register passed is %rbp.

Questions:

a. Is the second variant preferable to the first one from a compiler
perspective, as it would seem to be?
b. Is this portable across architectures as well?
c. Can we get this explicitly documented?

Hopefully this is a zero-code-change on the part of gcc, and a win-win as far
as forward compatibility is concerned.

Reply via email to