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.
