No target symbol hints for "jalr ra" instructions

[NonerKao]

Hi folks,

When I disassemble some executable using objdump -d ,
I can have symbol hints at call sites, such as:

ffffffe00000002e:       00002097                auipc   ra,0x2                                          
ffffffe000000032:       f24080e7                jalr    -220(ra) # ffffffe000001f52 <setup_vm>  
ffffffe000000036:       00000097                auipc   ra,0x0   
ffffffe00000003a:       034080e7                jalr    52(ra) # ffffffe00000006a <relocate>

If the target address happens to be 4096-byte-aligned to pc when doing auipc, the jalr then doesn't need any imm values. That is, I expect something like

ffffffe00000002e:       00002097                auipc   ra,0x2                                          
ffffffe000000032:       000080e7                jalr    0(ra) # ffffffe00000202e <setup_vm_xxx>  
ffffffe000000036:       00000097                auipc   ra,0x1   
ffffffe00000003a:       000080e7                jalr    0(ra) # ffffffe000001036 <relocate_xxx>

But what I can actually get is

ffffffe00000002e:       00002097                auipc   ra,0x2                                          
ffffffe000000032:       000080e7                jalr    ra
ffffffe000000036:       00000097                auipc   ra,0x1   
ffffffe00000003a:       000080e7                jalr    ra

The result of ra instead of 0(ra) is fine to me, but the symbol hints is gone. I am wondering if this is possible to be enhanced? With those symbols life would be a lot more easier in some application.

Thanks!

[palmer-dabbelt]

It should be pretty straight-forward, but I'm having some trouble actually figuring it out... It looks like maybe_print_address should be getting called here https://github.com/riscv/riscv-binutils-gdb/blob/d29899b4f3ded8dee0d1a767e0b97e27086171f0/opcodes/riscv-dis.c#L261

I'm afraid I'm not going to be able to look at it for a bit, sorry.

[jim-wilson]

It is the 's' case that needs to call maybe_print_address for a jalr. Normally this would be called unconditionally in the 'o' case for args matching "o(s)", but without the offset we have args matching "s" and so we need the call in the 's' case. But we probably don't want an unconditional call here, so I think it should just be for a jalr for now. I have a tentative patch that seems to work, but needs more testing, and a minimal testcase to reproduce.

[palmer-dabbelt]

Ah, thanks.

[jim-wilson]

Committed a patch upstream to fix this. It adds symbol names to 8 extra jalr insns in the linux kernel I tested it against.

[NonerKao]

Thanks!

[NonerKao]

Weird, I still find some symbols not being hinted.

the gnu-toolchain I used is built with:

$ git submodule status                                                                                                                  │·········
 248124ac2e5784cec5258d9daf91ebd2a4baa961 riscv-binutils-gdb (heads/riscv-binutils-2.29)
 b731149757b93ddc80e6e4b5483a6931d5f9ad60 riscv-gcc (heads/riscv-gcc-7.2.0)
 2f626de717a86be3a1fe39e779f0b179e13ccfbb riscv-glibc (2f626de)

A quick test:

riscv64-unknown-linux-gnu-objdump -d vmlinux | grep jalr | grep 000080e7 | less

000 080e7 stands for jalr ra, which is expected to be something like jalr (0)ra #fffffe012345678 symbol. But my binary shows jalr ra only.

Side note:
The binary is a vmlinux, and, as a basic test, I was checking if the _mcount symbol is collected right for the ftrace to work properly.

If you need any other information, please let me know. Thanks!

[jim-wilson]

If you want an up-to-date tree, then use the FSF one. That is where all development is happening now.
The patch you need is in the FSF binutils-2.30 release.

The riscv/riscv-binutils-gdb tree was necessary when binutils was not upstream, but now it is just an inconvenience, as maintaining two separate binutils trees is almost twice the work. At some point we will update the riscv-binutils-gdb tree to point at the FSF binutils-2.30 release branch, but we haven't had a chance to do that yet.

[NonerKao]

OK, thanks!