Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ELF View Support for SHN_COMMON-Relative Symbols #6111

Open
ehntoo opened this issue Nov 9, 2024 · 0 comments · May be fixed by #6185
Open

ELF View Support for SHN_COMMON-Relative Symbols #6111

ehntoo opened this issue Nov 9, 2024 · 0 comments · May be fixed by #6185
Labels
Component: DebugInfo Issue requires changes to the DebugInfo API Effort: Medium Issue should take < 1 month Impact: Medium Issue is impactful with a bad, or no, workaround Type: Enhancement Issue is a small enhancement to existing functionality

Comments

@ehntoo
Copy link

ehntoo commented Nov 9, 2024

What is the feature you'd like to have?
The ELF specification describes a Special Section Index SHN_COMMON that's defined as follows:

Symbols defined relative to this section are common symbols, such as FORTRAN COMMON or unallocated C external variables.

And also when describing symbol types:

The symbol labels a common block that has not yet been allocated. The symbol's value gives alignment constraints, similar to a section's sh_addralign member. That is, the link editor will allocate the storage for the symbol at an address that is a multiple of st_value. The symbol's size tells how many bytes are required.

Binary Ninja does not currently have any special handling for symbols with the SHN_COMMON section index, which leads to very unintuitive behavior when analyzing files that contain them.

Ideally, Binary Ninja would introduce an additional .common section similar to the current .extern section to contain properly sized and aligned objects with the SHN_COMMON special section index.

Is your feature request related to a problem?
While reverse-engineering a static library archive, I wanted to have visibility into all the constituent .o files at once. As a stop-gap alternative to getting upstream support (#2085), I used GCC to partially link the entire .a into a single .o file (riscv32-picolibc-elf-gcc -r -Og -g3 -o libch59xble.o -Wl,--whole-archive LIBCH59xBLE.a). When doing so, many symbols that were once STT_NOTYPE/SHN_UNDEF externs became STT_OBJECT/SHN_COMMON symbols that were no longer resolved by Binary Ninja.

Are any alternative solutions acceptable?
I can invent workarounds for my current usecase, but this would probably be good for Binary Ninja to support.

Additional Information:
You'll find the original static library as well as the partially-linked single object version in the zipfile attached to this issue. You may need my custom patch to the RISC-V architecture to get an entirely clean disassembly, as the RISC-V chip in question has some questionable RISC-V extensions.

Binary Ninja's disassembly of an example function in LIBCH59xBLE.a->rf_fh.o:

000012b0    void rf_rx_basic_rxProcess()

000012b0  0111       addi    sp, sp, -0x20
000012b2  97170000   auipc   a5, 0x1000
000012b6  83c7f731   lbu     a5, 0x31f(a5)
000012ba  06ce       sw      ra, 0x1c(sp) {__saved_ra}
000012bc  22cc       sw      s0, 0x18(sp) {__saved_s0}
000012be  26ca       sw      s1, 0x14(sp) {__saved_s1}
000012c0  4ac8       sw      s2, 0x10(sp) {__saved_s2}
000012c2  858b       andi    a5, a5, 0x1
000012c4  17170000   auipc   a4, 0x1000
000012c8  1307c730   addi    a4, a4, 0x30c

Relevant LIBCH59xBLE.a->rf_fh.o readelf snippets:

Relocation section '.rela.text.rf_rx_basic_rxProcess' at offset 0x8854 contains 164 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000002  00028a17 R_RISCV_PCREL_HI2 00000000   gBleIPPara + 1
00000002  00000033 R_RISCV_RELAX                1
00000006  00014c18 R_RISCV_PCREL_LO1 00000002   .L0  + 0
00000006  00000033 R_RISCV_RELAX                0
00000014  00028a17 R_RISCV_PCREL_HI2 00000000   gBleIPPara + 0
00000014  00000033 R_RISCV_RELAX                0
00000018  00014d18 R_RISCV_PCREL_LO1 00000014   .L0  + 0
00000018  00000033 R_RISCV_RELAX                0

Symbol table '.symtab' contains 703 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
   650: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND gBleIPPara

Binary Ninja's disassembly of an example function in libch59xble.o. Relocations for gBleIPPara at 0x2be62/0x2be66 and 0x2be74/0x2be78 have gone unfilled:

0002be60    void rf_rx_basic_rxProcess()

0002be60  0111       addi    sp, sp, -0x20
0002be62  97070000   auipc   a5, 0x0
0002be66  83c70700   lbu     a5, 0x0(a5)  {.L0 }
0002be6a  06ce       sw      ra, 0x1c(sp) {__saved_ra}
0002be6c  22cc       sw      s0, 0x18(sp) {__saved_s0}
0002be6e  26ca       sw      s1, 0x14(sp) {__saved_s1}
0002be70  4ac8       sw      s2, 0x10(sp) {__saved_s2}
0002be72  858b       andi    a5, a5, 0x1
0002be74  17070000   auipc   a4, 0x0
0002be78  13070700   mv      a4, a4  {.L0 }

libch59xble.o readelf snippets:

Relocation section '.rela.text.rf_rx_basic_rxProcess' at offset 0xb9680 contains 164 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000002  00325a17 R_RISCV_PCREL_HI2 00000004   gBleIPPara + 1
00000002  00000033 R_RISCV_RELAX                1
00000006  00246018 R_RISCV_PCREL_LO1 00000002   .L0  + 0
00000006  00000033 R_RISCV_RELAX                0
00000014  00325a17 R_RISCV_PCREL_HI2 00000004   gBleIPPara + 0
00000014  00000033 R_RISCV_RELAX                0
00000018  00246118 R_RISCV_PCREL_LO1 00000014   .L0  + 0
00000018  00000033 R_RISCV_RELAX                0

Symbol table '.symtab' contains 13076 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
 12890: 00000004    40 OBJECT  GLOBAL DEFAULT  COM gBleIPPara

shn_common_files.zip
@xusheng6 xusheng6 added Type: Enhancement Issue is a small enhancement to existing functionality Effort: Medium Issue should take < 1 month Impact: Medium Issue is impactful with a bad, or no, workaround Component: DebugInfo Issue requires changes to the DebugInfo API labels Nov 12, 2024
@ehntoo ehntoo linked a pull request Nov 24, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Component: DebugInfo Issue requires changes to the DebugInfo API Effort: Medium Issue should take < 1 month Impact: Medium Issue is impactful with a bad, or no, workaround Type: Enhancement Issue is a small enhancement to existing functionality
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Implement SHN_COMMON symbol handling ehntoo/binaryninja-api
2 participants
@ehntoo @xusheng6