Hand-written assembly and Python API

Hand-written assembly and Python API

[Jan Vrany]

Hi folks,

I'm trying to debug a code that uses a handful of
hand-written assembly routines. For example, one of
them looks like (its RISC-V but that does not matter):

    .text
    .globl returnFromJIT1
    .type returnFromJIT1,function
    .align 2
returnFromJIT1:
    .cfi_startproc
    sd a0,248(s10)
    sd s11,32(s10)
    li a0, 17
    li a1, 1
    j cInterpreterFromJIT
    .cfi_endproc
    .size   returnFromJIT1, .-returnFromJIT1

   .text
   .globl ...

GDB clealy knows "something" about the assembly routines, it shows
the source properly and 'info symbol' works too:

   (gdb) info symbol 0x3ff75eca24
   returnFromJIT1 in section .text of /opt/riscv/sysroot/tmp/jdk/lib/default/libj9jit29.so

The problem is how to figure out I'm in (say) `returnFromJIT1` routine
using Python API:

   (gdb) py print(gdb.block_for_pc(0x3ff75eca24).function)
   None

The only way I can think of is to parse value of `gdb.format_address()`:

   (gdb) py print(gdb.format_address(0x3ff75eca24))
   0x3ff75eca24 <returnFromJIT1>

which is bit awkward (but doable!).

Question is: is there a better way? I can modify the assembly source
too if there's some directive that may help GDB (.cfi_startproc / .cfi_endproc
is clearly not enough). Or do I have to roll up sleeves and implement python
API for minimal symbols?

Thanks!

Jan

Re: Hand-written assembly and Python API

[Simon Marchi]

On 2022-04-29 08:32, Jan Vrany via Gdb wrote:
> Hi folks,
>
> I'm trying to debug a code that uses a handful of
> hand-written assembly routines. For example, one of
> them looks like (its RISC-V but that does not matter):
>
>     .text
>     .globl returnFromJIT1
>     .type returnFromJIT1,function
>     .align 2
> returnFromJIT1:
>     .cfi_startproc
>     sd a0,248(s10)
>     sd s11,32(s10)
>     li a0, 17
>     li a1, 1
>     j cInterpreterFromJIT
>     .cfi_endproc
>     .size   returnFromJIT1, .-returnFromJIT1
>
>    .text
>    .globl ...
>
> GDB clealy knows "something" about the assembly routines, it shows
> the source properly and 'info symbol' works too:
>
>    (gdb) info symbol 0x3ff75eca24
>    returnFromJIT1 in section .text of /opt/riscv/sysroot/tmp/jdk/lib/default/libj9jit29.so
>
> The problem is how to figure out I'm in (say) `returnFromJIT1` routine
> using Python API:
>
>    (gdb) py print(gdb.block_for_pc(0x3ff75eca24).function)
>    None
>
> The only way I can think of is to parse value of `gdb.format_address()`:
>
>    (gdb) py print(gdb.format_address(0x3ff75eca24))
>    0x3ff75eca24 <returnFromJIT1>
>
> which is bit awkward (but doable!).
>
> Question is: is there a better way? I can modify the assembly source
> too if there's some directive that may help GDB (.cfi_startproc / .cfi_endproc
> is clearly not enough). Or do I have to roll up sleeves and implement python
> API for minimal symbols?

I was going to say "returnFromJIT1" is a minimal symbol, but you clearly
know that already.  There is DWARF debug info for assembly when building
with -g (at least when building with gcc / gas), but it only contains
line statements, which allows GDB to show where you are in the source
file (instead of showing disassembly).  You won't be able to look up a
block from that.

I don't know of a way to do it with the current API, unfortunately.

Simon

Re: Hand-written assembly and Python API

[Jan Vrany]

On Fri, 2022-04-29 at 08:54 -0400, Simon Marchi wrote:
> On 2022-04-29 08:32, Jan Vrany via Gdb wrote:
> > Hi folks,
> >
> > I'm trying to debug a code that uses a handful of
> > hand-written assembly routines. For example, one of
> > them looks like (its RISC-V but that does not matter):
> >
> >     .text
> >     .globl returnFromJIT1
> >     .type returnFromJIT1,function
> >     .align 2
> > returnFromJIT1:
> >     .cfi_startproc
> >     sd a0,248(s10)
> >     sd s11,32(s10)
> >     li a0, 17
> >     li a1, 1
> >     j cInterpreterFromJIT
> >     .cfi_endproc
> >     .size   returnFromJIT1, .-returnFromJIT1
> >
> >    .text
> >    .globl ...
> >
> > GDB clealy knows "something" about the assembly routines, it shows
> > the source properly and 'info symbol' works too:
> >
> >    (gdb) info symbol 0x3ff75eca24
> >    returnFromJIT1 in section .text of /opt/riscv/sysroot/tmp/jdk/lib/default/libj9jit29.so
> >
> > The problem is how to figure out I'm in (say) `returnFromJIT1` routine
> > using Python API:
> >
> >    (gdb) py print(gdb.block_for_pc(0x3ff75eca24).function)
> >    None
> >
> > The only way I can think of is to parse value of `gdb.format_address()`:
> >
> >    (gdb) py print(gdb.format_address(0x3ff75eca24))
> >    0x3ff75eca24 <returnFromJIT1>
> >
> > which is bit awkward (but doable!).
> >
> > Question is: is there a better way? I can modify the assembly source
> > too if there's some directive that may help GDB (.cfi_startproc / .cfi_endproc
> > is clearly not enough). Or do I have to roll up sleeves and implement python
> > API for minimal symbols?
>
> I was going to say "returnFromJIT1" is a minimal symbol, but you clearly
> know that already.  There is DWARF debug info for assembly when building
> with -g (at least when building with gcc / gas), but it only contains
> line statements, which allows GDB to show where you are in the source
> file (instead of showing disassembly).  You won't be able to look up a
> block from that.
>
> I don't know of a way to do it with the current API, unfortunately.
>
> Simon

Thanks! 
I was secretly hoping you might know some trick I'm not aware of...

Jan