[Bug c/107736] New: call to a function, generated by inline asm, is off by one byte

[Bug c/107736] New: call to a function, generated by inline asm, is off by one byte

[miladfarca at gmail dot com]

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

            Bug ID: 107736
           Summary: call to a function, generated by inline asm, is off by
                    one byte
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: miladfarca at gmail dot com
  Target Milestone: ---

Tested on Arm64, PPC64 and s390x with gcc 12.

```
const char num = 0;

void call();
asm( ".globl call            \n"
     ".type call, %function  \n"
     ".hidden call           \n"
     "call:                  \n"
     // Just return.
     "ret                    \n");

int main(){
 call();
 return 0;
}
```
TL;DR:
The instruction generated for `call();` is jumping to the address of `num` and
causing a crash as `num` is not an instruction, seems to be an alignment issue?

Details:
- This doesn't happen on x64 and call is made to the correct address. It also
does not happen with clang on either platforms (tested with version 6.0).

- gcc is putting "call" into .rodata section of memory including on x64. Not
sure if this is a separate bug or intentional. clang is putting it under
".text" as expected.

- gcc is incorrectly assuming `&num` is the address of `call` and jumping to it
which is off by 1 byte.

- Workarounds include adding either ".text \n" or ".align 8" to the inline asm,
tho call should be made to the correct address even without them?

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
           Keywords|                            |inline-asm
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>- Workarounds include adding either ".text \n" or ".align 8" to the inline asm, tho call should be made to the correct address even without them?

That is NOT a workaround but the correct fix to the toplevel inline-asm.

Toplevel inline-asm will be emitted without any knowledge of the current
section. It could even be inside the data section or even worse the debugging
info section. There is no knowledge of the current alignment in there either.

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[miladfarca at gmail dot com]

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

--- Comment #2 from mfarca <miladfarca at gmail dot com> ---
> Toplevel inline-asm will be emitted without any knowledge of the current section.
So this is a limitation of gcc I guess? as clang does have the knowledge on
which is which.

The main issue still persists as call is made to the wrong address.

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=107738

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>So this is a limitation of gcc I guess? 
I suspect it just accidently works for clang/LLVM. The section at the time was
a text section when clang emits the assembler (most likely it assumes it is the
first thing in the file)
You could define a global symbol there in the top-level inline-asm and think it
should work as a read-write symbol but it does not; there is no way clang would
know that was what you think it should do.


Note I filed PR 107738 for some of the more common mistakes of top-level
inline-asm

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[miladfarca at gmail dot com]

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

--- Comment #4 from mfarca <miladfarca at gmail dot com> ---
Thanks for creating the issue for improving documentation.

Could you then clarify if call to the incorrect address is a bug or not?
instructions are allowed to be under `.rodata` section as this section is still
executable and works fine on x64, more on this:
https://stackoverflow.com/a/44938843

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to mfarca from comment #4)
> Thanks for creating the issue for improving documentation.
> 
> Could you then clarify if call to the incorrect address is a bug or not?
> instructions are allowed to be under `.rodata` section as this section is
> still executable and works fine on x64, more on this:
> https://stackoverflow.com/a/44938843

x64 does not have an alignment requirement for instructions while the other
targets do. That is all.

x64 does not have an alignment requirement because the instructions are all
different sizes including some single byte instructions.

This is an ISA difference really and not really a GCC question at this point.

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 33932.

*** This bug has been marked as a duplicate of bug 33932 ***