Fix debug info support

[koute]

It seems like debug info is completely broken on the newest toolchain; the test_basic_debug_info_32 and test_basic_debug_info_64 tests we have fail here:

    assert_eq!(frame.line(), Some(line as u32 + 1));
    assert_eq!(frame.full_name().unwrap().to_string(), "read_u32");

The line is wrong, and the strings in the debug info are all "cap" for some reason.

[koute]

@jarkkojs You can try tackling this once you finish updating PolkaVM in polkadot-sdk.

[jarkkojs]

@jarkkojs You can try tackling this once you finish updating PolkaVM in polkadot-sdk.

+1

[jarkkojs]

DW_AT_name [DW_FORM_strp] : (indirect string, .debug_str+0x0): cap

@koute, verified with rz-bin -d: https://book.rizin.re/src/tools/rz-bin/intro.html

This is by far the most reliable tool to dump DWARF (highly recommended).

[jarkkojs]

@koute, so this now happens also when checking out with the tip commit as:

commit a3dbdd0ebb73912b57cf4865b5be06a598ff0494 (HEAD)
Author: Jarkko Sakkinen <[email protected]>
Date:   Fri Oct 25 20:16:37 2024 +0300

    Fix metadata aligment

    Closes: #199
    Suggested-by: Jan Bujak <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>

[jarkkojs]

Patched as a test build-benchmarks.sh so that RUSTFLAGS="dwarf-version=2/3/4" but no luck.

https://doc.rust-lang.org/beta/unstable-book/compiler-flags/dwarf-version.html

[jarkkojs]

$ objdump -s -j .debug_str ./guest-programs/target/riscv32emac-unknown-none-polkavm/no-lto/test-blob|head -20

./guest-programs/target/riscv32emac-unknown-none-polkavm/no-lto/test-blob:     file format elf32-little

Contents of section .debug_str:
 0000 3c262875 33322c20 75333229 20617320  <&(u32, u32) as 
 0010 636f7265 3a3a666d 743a3a44 65627567  core::fmt::Debug
 0020 3e3a3a7b 76746162 6c655f74 7970657d  >::{vtable_type}
 0030 00636170 0070616e 69636b69 6e670041  .cap.panicking.A
 0040 6c69676e 6d656e74 00266d75 74206479  lignment.&mut dy
 0050 6e20636f 72653a3a 666d743a 3a577269  n core::fmt::Wri
 0060 74650073 656c6600 666d743c 7533322c  te.self.fmt<u32,
 0070 20753332 3e00636f 6c6c6563 74696f6e   u32>.collection
 0080 7300616c 6c6f635f 73697a65 007b696d  s.alloc_size.{im
 0090 706c2331 7d00616c 6c6f633c 31303438  pl#1}.alloc<1048
 00a0 3537363e 006d6170 5f657272 3c636f72  576>.map_err<cor
 00b0 653a3a70 74723a3a 6e6f6e5f 6e756c6c  e::ptr::non_null
 00c0 3a3a4e6f 6e4e756c 6c3c5b75 385d3e2c  ::NonNull<[u8]>,
 00d0 20636f72 653a3a61 6c6c6f63 3a3a416c   core::alloc::Al
 00e0 6c6f6345 72726f72 2c20616c 6c6f633a  locError, alloc:
 00f0 3a636f6c 6c656374 696f6e73 3a3a5472  :collections::Tr

All Dw_AT_name attributes point to offset zero. There's other strings too but I don't see them being used in the DWARF data.

[jarkkojs]

@koute, @athei: I have some new information.

I've now been able to verify that our targets generate correct DWARF. I verified this by creating a dummy compilation unit and compiling that with our target JSON:

$ cat test.rs
#![feature(no_core)]
#![feature(lang_items)]
#![no_core]
#![no_std]
#[lang = "sized"]
pub trait Sized {}
#[lang = "copy"]
pub trait Copy {}

pub fn dummy() -> u32 {
    return 42;
}

$ rustc +nightly --crate-type lib --target ~/work/github.com/jarkkojs/polkavm/crates/polkavm-linker/riscv32emac-unknown-none-polkavm.json -C debuginfo=2 test.rs
warning: the feature `lang_items` is internal to the compiler or standard library
 --> test.rs:2:12
  |
2 | #![feature(lang_items)]
  |            ^^^^^^^^^^
  |
  = note: using it is strongly discouraged
  = note: `#[warn(internal_features)]` on by default

warning: 1 warning emitted

$ riscv64-linux-gnu-objdump --dwarf=info libtest.rlib     
In archive libtest.rlib:

lib.rmeta:     file format elf32-littleriscv


test.test.ff7e5d1d16ad8e2f-cgu.0.rcgu.o:     file format elf32-littleriscv

Contents of the .debug_info section:

  Compilation Unit @ offset 0:
   Length:        0x49 (32-bit)
   Version:       4
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0): clang LLVM (rustc version 1.85.0-nightly (a224f3807 2024-12-09))
    <10>   DW_AT_language    : 28	(Rust)
    <12>   DW_AT_name        : (indirect string, offset: 0x41): test.rs/@/test.ff7e5d1d16ad8e2f-cgu.0
    <16>   DW_AT_stmt_list   : 0
    <1a>   DW_AT_comp_dir    : (indirect string, offset: 0x67): /home/jarkko
    <1e>   DW_AT_low_pc      : 0
    <22>   DW_AT_high_pc     : 0x6
 <1><26>: Abbrev Number: 2 (DW_TAG_namespace)
    <27>   DW_AT_name        : (indirect string, offset: 0x74): test
 <2><2b>: Abbrev Number: 3 (DW_TAG_subprogram)
    <2c>   DW_AT_low_pc      : 0
    <30>   DW_AT_high_pc     : 0x6
    <34>   DW_AT_frame_base  : 1 byte block: 52 	(DW_OP_reg2 (sp))
    <36>   DW_AT_linkage_name: (indirect string, offset: 0x79): _ZN4test5dummy17hf644d63975682d1bE
    <3a>   DW_AT_name        : (indirect string, offset: 0x9c): dummy
    <3e>   DW_AT_decl_file   : 1
    <3f>   DW_AT_decl_line   : 10
    <40>   DW_AT_type        : <0x45>
    <44>   DW_AT_external    : 1
 <2><44>: Abbrev Number: 0
 <1><45>: Abbrev Number: 4 (DW_TAG_base_type)
    <46>   DW_AT_name        : (indirect string, offset: 0xa2): u32
    <4a>   DW_AT_encoding    : 7	(unsigned)
    <4b>   DW_AT_byte_size   : 4
 <1><4c>: Abbrev Number: 0

This is important result in the sense that it excludes rustc as the root cause but makes me wonder what else possibly could go wrong...

[athei]

So the linker (lld I assume) is the culprit then?

[jarkkojs]

So the linker (lld I assume) is the culprit then?

Not fully excluded at least. I've used four different linkers with same results so if it is linker, then it must be the flags given to the linker, not a linker bug.

EDIT: actually this was incorrect as PolkaVM RISC-V targets are compiled with LLVM ld. So yeah I could try just as a comparative test to modify the JSON file to use some other linker and see if results match. I.e. linker bug is not fully excluded.

[jarkkojs]

New findings if I:

cargo +nightly t -p polkavm tests::test_basic_debug_info_32 -- --nocapture --test-threads=1

Then:

running 1 test
test tests::test_basic_debug_info_32 ... thread 'tests::test_basic_debug_info_32' panicked at crates/polkavm/src/tests.rs:2611:5:
assertion `left == right` failed
  left: Some(35)
 right: Some(59)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
FAILED

failures:

failures:
    tests::test_basic_debug_info_32

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 1513 filtered out; finished in 0.23s

error: test failed, to rerun pass `-p polkavm --lib`

Also DWARF looks at least on surface correct, i.e. everything is not point to the offset zero of .debug_str.

Testing was done on top of #240.

[jarkkojs]

New findings if I:

cargo +nightly t -p polkavm tests::test_basic_debug_info_32 -- --nocapture --test-threads=1

Then:

running 1 test
test tests::test_basic_debug_info_32 ... thread 'tests::test_basic_debug_info_32' panicked at crates/polkavm/src/tests.rs:2611:5:
assertion `left == right` failed
  left: Some(35)
 right: Some(59)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
FAILED

failures:

failures:
    tests::test_basic_debug_info_32

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 1513 filtered out; finished in 0.23s

error: test failed, to rerun pass `-p polkavm --lib`

Also DWARF looks at least on surface correct, i.e. everything is not point to the offset zero of .debug_str.

Testing was done on top of #240.

Was not the case, still the same results. I overlooked something ;-)

[jarkkojs]

Checking for .debug_str_offsets section. I don't actually know what is used for, just became aware of its existence.

[jarkkojs]

Yeah so to figure out is how these two sections work and interact together... And obviously check what they contain ATM. Before going to holiday I've completely ignored .debug_str_offsets because I've been unaware of its existence...