Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb?

[Jiang, Haochen]

> From: Tom de Vries <tdevries@suse.de>
> Sent: Monday, August 25, 2025 10:34 PM
> 
> On 8/25/25 11:26, Alexander Monakov wrote:
> >
> > On Mon, 25 Aug 2025, Sam James wrote:
> >
> >> Jan Beulich <jbeulich@suse.com> writes:
> >>
> >>> On 25.08.2025 04:42, Jiang, Haochen wrote:
> >>>> Does anyone know the reason on that? It is weird to me.
> >>>
> >>> Same here; see https://sourceware.org/pipermail/gdb-patches/2019-
> February/155347.html.
> >>> That patch might require re-basing and some work to be up-to-date again,
> >>> but fundamentally it still looks applicable. I don't really understand why stuff
> >>> like this isn't allowed in. Pedro's desire for a testcase is understandable,
> >>> but shouldn't block such a patch (there was a 2nd one s well) for this
> >>> many years.
> >>
> >> I didn't realise a patch was rotting for this. There's Alexander's
> >> PR28999 (and a few other either dupes or very-related bugs) too.
> >>
> >> While I can understand wanting a testcase, tdep is really in a sorry
> >> state for x86 anyway, and this clearly makes it better. Perhaps with
> >> Haochen's interest, we can finally get it in. But I don't see any
> >> specific x86 maintainers for gdb.
> >
> > I hope the bug is fixed by a more comprehensive patchset from Tom, which
> > has already landed:
> > https://inbox.sourceware.org/gdb-patches/e5282a4b-5d9f-4891-b9b8-
> 45ded54ec6ee@suse.de/
> >
> > Haochen's question still stands, I guess.

I happened to have a look at gdb code since someone encountered similar
rip relative address issue and asking me why. And we finally found that the
problem is on the usage of that table.

I still believe we need to do something in the table handling to eliminate the
gap between disassembler and gdb since it is said to be the table is the same,
indicating the usage should also be the same.

Jan's patch in 2019 is doing that (while we need to work around VZEROALL and
VZEROUPPER). And I knew that a testcase to cover everything is tricky since ...

> 
> I grepped a bit in the gas testsuite for VPBLENDW and constructed a gdb
> unit test that passes with workaround but fails without:

... I suppose VPBLENDW might not be the only inst meeting the issue.

We need to either work on the similar way Jan's patch does and polish them
or totally separate the usage of the table if gdb would like to still keep the
current logic (which I do not prefer since it is make things over complicated).

Thx,
Haochen