[Bug c/116483] New: RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[Bug c/116483] New: RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

            Bug ID: 116483
           Summary: RFE: a notion for asm goto to indicate all labels in
                    the function may be jumped to
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

Hi,

We currently have some code using computed goto:

goto *table[index];

But for satisfying some tools analyzing the generated machine code, we need to
encode the address of the jump instruction and the address of the table in a
special section, something like.

asm volatile (
  "1:"
  "jr %0\n\t"
  ".pushsection .metainfo\n\t"
  "  .8byte 1b\n\t"
  "  .8byte %1\n\t"
  ".popsection"
  : "r"(table[index]), "r"(table)
);

But this won't work: the compiler does not know this asm block ever jumps.  To
make it aware of the jump, we have to do:

asm goto (
  "1:"
  "jr %0\n\t"
  ".pushsection .metainfo\n\t"
  "  .8byte 1b\n\t"
  "  .8byte %1\n\t"
  ".popsection"
  : "r"(table[index]), "r"(table)
  :
  :
  : label1, label2, label3, label4, label5 /* ... */ 
);

Unfortunately this is nasty with a hundred of labels.  So IMO it may be useful
to add a notion to indicate this asm goto block may jump into any label in the
same function, maybe like...

asm goto (
  "1:"
  "jr %0\n\t"
  ".pushsection .metainfo\n\t"
  "  .8byte 1b\n\t"
  "  .8byte %1\n\t"
  ".popsection"
  : "r"(table[index]), "r"(table)
  :
  :
  : "anywhere"
);

?

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
FWIW in the examples "r"(table) should be "i"(table) instead.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-08-26
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am trying to understand the use case here. Is it for someone analyzing the
code after the fact or for something else.

Can you provide a full example of what you want and explain why computed goto
cannot be used instead of the inline-asm.

It is not obvious from reading your explanation why you need the asm goto here.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> But for satisfying some tools analyzing the generated machine code

Also this sounds like a limitation in the tool analyzing the generated code and
outside of gcc; I know helping the tool along is useful but that sounds like a
workaround instead of fixing the tool.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> > But for satisfying some tools analyzing the generated machine code
> 
> Also this sounds like a limitation in the tool analyzing the generated code
> and outside of gcc; I know helping the tool along is useful but that sounds
> like a workaround instead of fixing the tool.

The tool is objtool from the Linux kernel.  It needs to know all the locations
that a branch instruction may jump into.  In the past objtool only works on
x86, where objtool can find the relocation against the nearest instruction
before the jump instruction, which points to the goto table.

But on RISC machines (for example LoongArch) this approach does not work: with
-fsection-anchors (often enabled at -O1 or above) the relocation entry may
actually points to the section anchor instead of the table.  And w/o the help
of the compiler we'd have to figure out the address of the goto table by
interpreting the LoongArch machine code, and doing so is not easy.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I.e. we want to refer the exact location of the jump instruction (not an
instruction preparing for it) in the asm, and doing so is not possible with
computed goto.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Is synthesizing the .metainfo section in the compiler not an option for some
reason? Sounds straightforward to implement on the RTL level (with the caveats
that you'd only get that for future gcc releases, and would need to implement
that functionality separately for llvm, if necessary).

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #6)
> with the caveats that you'd only get that for future gcc releases

I think this caveat is fine as if adding the other feature to asm goto you
would also have to wait for a future version of GCC too.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #6)
> Is synthesizing the .metainfo section in the compiler not an option for some
> reason? Sounds straightforward to implement on the RTL level (with the
> caveats that you'd only get that for future gcc releases, and would need to
> implement that functionality separately for llvm, if necessary).

Is there any pointer how to implement this instead?

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #8)
> Is there any pointer how to implement this instead?

It may be sufficient to change

(define_insn "@tablejump<mode>"
  [(set (pc)
        (match_operand:P 0 "register_operand" "e"))
   (use (label_ref (match_operand 1 "" "")))]
  ""
  "jr\t%0"
  [(set_attr "type" "jump")
   (set_attr "mode" "none")])

such that instead of providing the string template "jr\t%0" you instead do

{ return loongarch_output_tablejump(...); }

as already done for division, some moves, branches, ... and in that function
you emit .pushsection ... .popsection as necessary, in addition to "jr\t%0".

But are you sure it is really necessary? I see that objtool already has support
for inspecting relocations, and that seems sufficient for reaching the jump
table from the jump instruction on Loongarch.

I noticed that this will be a topic of discussion on the upcoming kernel BoF on
the GNU Cauldron, in context of objtool on arm64:

https://inbox.sourceware.org/gcc/87h6akzwdq.fsf@oracle.com/T/

and was previously discussed on kernel mailing lists, with some particularly
illuminating responses from Michael Matz:

https://lore.kernel.org/linux-arm-kernel/YyLmhUxTUaNzaieC@hirez.programming.kicks-ass.net/T/#m10f5b79259ad7fe62129ac7db790fe53f7ed8d8e

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|WAITING                     |RESOLVED

--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #9)
> (In reply to Xi Ruoyao from comment #8)
> > Is there any pointer how to implement this instead?
> 
> It may be sufficient to change
> 
> (define_insn "@tablejump<mode>"
>   [(set (pc)
>         (match_operand:P 0 "register_operand" "e"))
>    (use (label_ref (match_operand 1 "" "")))]
>   ""
>   "jr\t%0"
>   [(set_attr "type" "jump")
>    (set_attr "mode" "none")])
> 
> such that instead of providing the string template "jr\t%0" you instead do
> 
> { return loongarch_output_tablejump(...); }

It only handles switch statements, not computed gotos.  I've already submitted
the patch for switch statements but it was Nack'ed by LoongArch port maintainer
Chenghua Xu (off the list).

> But are you sure it is really necessary? I see that objtool already has support for inspecting relocations, and that seems sufficient for reaching the jump table from the jump instruction on Loongarch.

I guess Chenghua shares the same opinion...  Maybe we'll have to improve
objtool.

P.S. the difference between LoongArch and x86 (which is the only port supported
by objtool before LoongArch) is: on x86 the relocation is directly on the jmp
instruction and to the table.  But on LoongArch the relocation is on some
instruction prior to the jump instruction (with scheduling it's not easy to
tell the offset of that instruction from the jump instruction); and because
LoongArch has -fsection-anchors the relocation may actually points to a section
anchor instead of the table itself.  So we'll need some non-trivial data flow
analysis in objtool.

I'm closing as WONTFIX as it seems Chenghua (and some kernel developers)
dislike adding the metainfo generation to GCC just for objtool.

[Bug c/116483] RFE: a notion for asm goto to indicate all labels in the function may be jumped to

[amonakov at gcc dot gnu.org]

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

--- Comment #11 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
> It only handles switch statements, not computed gotos.

Oh, right, apologies for misunderstanding your question like that. For computed
gotos it is indeed not so easy, especially if there is more than one computed
goto in a function.