[Bug c/105704] New: jump tables are not marked with @STT_OBJECT, disassembly wrong

[Bug c/105704] New: jump tables are not marked with @STT_OBJECT, disassembly wrong

[jur at sysgo dot com]

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

            Bug ID: 105704
           Summary: jump tables are not marked with @STT_OBJECT,
                    disassembly wrong
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jur at sysgo dot com
  Target Milestone: ---

It seems that the compiler sometimes creates jump tables when using
switch/case. The generated output looks like (PowerPC e5500 output from
-save-temps):
addis 9,2,.LC0@toc@ha
 rldic 3,3,2,46
 .LVL15:
 ld 8,.LC0@toc@l(9)
 lwax 9,8,3
 add 9,9,8
 mtctr 9
 bctr
 .p2align 2
 .align 2
 .L6:
 .long .L5-.L6
 .long .L7-.L6
 .long .L8-.L6
 .long .L9-.L6
 .long .L10-.L6
 .long .L11-.L6
 .long .L19-.L6
 .long .L19-.L6
 .long .L19-.L6
 .long .L12-.L6
 .p2align 4,,15
 .L12:
 .loc 1 159 0
 ld 9,224(13)

The disassembly looks like:
 ffffff800004a654: 7d 29 03 a6 mtctr r9
 ffffff800004a658: 4e 80 04 20 bctr
 ffffff800004a65c: 00 00 00 64 .long 0x64
 ffffff800004a660: 00 00 01 a4 .long 0x1a4
 ffffff800004a664: 00 00 02 d4 .long 0x2d4
 ffffff800004a668: 00 00 01 d4 .long 0x1d4
 ffffff800004a66c: 00 00 02 54 .long 0x254
 ffffff800004a670: 00 00 01 04 .long 0x104
 ffffff800004a674: ff ff fe b8 fmsub f31,f31,f26,f31
 ffffff800004a678: ff ff fe b8 fmsub f31,f31,f26,f31
 ffffff800004a67c: ff ff fe b8 fmsub f31,f31,f26,f31
 ffffff800004a680: 00 00 00 64 .long 0x64

The problem is that the offset for the bctr is interpreted as fmsub
instruction. 

There is something missing like:
.type .L6 @STT_OBJECT

This would declare it as data. But then you may need to declare the code after
this as STT_FUNC again.

The example code comes from an older GCC version, but it seems that the
behaviour did not change in GCC 11.3.0.

[Bug target/105704] jump tables are not marked with @STT_OBJECT, disassembly wrong

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note what you are proposing won't work IIRC. The way arm and aarch64 handle it
is via a separate section to record if it is data or code.

[Bug target/105704] jump tables are not marked with @STT_OBJECT, disassembly wrong

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Arm uses mapping symbols, which are special symbols in the object file that are
used by disassemblers to understand the content of code sections.  But that's
not the primary reason we use such annotations and I wouldn't propose such
annotations for other targets unless there were compelling additional reasons
for their use.

[Bug target/105704] jump tables are not marked with @STT_OBJECT, disassembly wrong

[jur at sysgo dot com]

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

--- Comment #3 from Jürgen Urban <jur at sysgo dot com> ---
>From security point of view the compiler should not put jump tables into the
code, because this creates new attack vectors. The code might be used by
different types of security attacks, as it can contain instructions which are
special (cache or FPU operations for example). A better location would be a
different section which can be configured to be not executable.
For me it looks like it could be easy to add the @STT_OBJECT feature while it
would help to correctly disassemble the code.
When you have to analyse the code for security or safety reasons, this helps
with automated analysis. For example you might have to prove full code coverage
when testing and the compiler should not create code which is never
executed/tested. The fmsub instruction can never be executed. For such an
analysis you get into problems, as you have to explain why the code is never
executed. Actually the problem was detected as the code should not contain any
floating point instructions (because FPU is disabled), but the disassembly has
shown that this was not the case.