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.

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

Dummy Overlapping Line Program Range produced for WASM Target #79410

Open
mitsuhiko opened this issue Nov 25, 2020 · 3 comments
Open

Dummy Overlapping Line Program Range produced for WASM Target #79410

mitsuhiko opened this issue Nov 25, 2020 · 3 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mitsuhiko
Copy link
Contributor

mitsuhiko commented Nov 25, 2020

The following minimal WASM example:

#![no_std]

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
pub fn internal_func() {
}

Produces a line number program in DWARF with what appears to decode to two overlapping ranges:

Line Number Rows:
<pc>        [lno,col]
0x00000000  [   4, 0] NS uri: "src/lib.rs"
0x0000001d  [   5, 5] NS PE
0x00000021  [   0, 5]
0x00000023  [   0, 5] ET
0x00000002  [   9, 0] NS
0x00000003  [  10, 2] NS PE
0x00000005  [  10, 2] NS ET

The output here is from the gimli dwarfdump tool but you can basically see that from pc 0x00 a sequence is started and ends at 0x23 which is the end of the program. The actual function internal_func sits at 0x2 and ends at 0x5. Since DWARF does not permit code at 0x0 it would appear that rustc pads out the file for two bytes and places "nothing" at 0x0.

DWARF does not talk much about overlapping sequences but it does talk about how sequences have to be contiguous:

A series of contiguous target machine instructions. One compilation unit may emit multiple sequences (that is, not all instructions within a compilation unit are assumed to be contiguous).

We currently take advantage of this fact and only consider a single sequence per PC. Right now we accidentally pick up on the first sequence which starts at 0. We can work around this by skipping sequences at zero but it seems to be a bug that this dummy sequence is generated in the first place.

Meta

$ rustc --version --verbose
rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-apple-darwin
release: 1.48.0
LLVM version: 11.0

It also happens on nightly:

$ rustc +nightly --version --verbose
rustc 1.50.0-nightly (825637983 2020-11-18)
binary: rustc
commit-hash: 8256379832b5ecb7f71e8c5e2018446482223c12
commit-date: 2020-11-18
host: x86_64-apple-darwin
release: 1.50.0-nightly
@mitsuhiko mitsuhiko added the C-bug Category: This is a bug. label Nov 25, 2020
@jonas-schievink jonas-schievink added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 25, 2020
@mstange
Copy link

mstange commented Aug 3, 2022

I cannot reproduce this with the provided testcase on Rust 1.62.0.

However, the test case is incomplete, so I may not be testing the same thing.

@mitsuhiko Which target were you using? wasm32-unknown-unknown or wasm32-wasi? Were you building a debug or a release configuration? What did your Cargo.toml look like?

I tried with the following Cargo.toml, and cargo build --release --target=wasm32-unknown-unknown:

[package]
name = "wasm-zero-address"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[profile.release]
debug = true

Here's the result of llvm-dwarfdump --debug-line ./target/wasm32-unknown-unknown/release/wasm_zero_address.wasm:

./target/wasm32-unknown-unknown/release/wasm_zero_address.wasm: file format WASM

.debug_line contents:
debug_line[0x00000000]
Line table prologue:
    total_length: 0x0000004c
          format: DWARF32
         version: 4
 prologue_length: 0x00000022
 min_inst_length: 1
max_ops_per_inst: 1
 default_is_stmt: 1
       line_base: -5
      line_range: 14
     opcode_base: 13
standard_opcode_lengths[DW_LNS_copy] = 0
standard_opcode_lengths[DW_LNS_advance_pc] = 1
standard_opcode_lengths[DW_LNS_advance_line] = 1
standard_opcode_lengths[DW_LNS_set_file] = 1
standard_opcode_lengths[DW_LNS_set_column] = 1
standard_opcode_lengths[DW_LNS_negate_stmt] = 0
standard_opcode_lengths[DW_LNS_set_basic_block] = 0
standard_opcode_lengths[DW_LNS_const_add_pc] = 0
standard_opcode_lengths[DW_LNS_fixed_advance_pc] = 1
standard_opcode_lengths[DW_LNS_set_prologue_end] = 0
standard_opcode_lengths[DW_LNS_set_epilogue_begin] = 0
standard_opcode_lengths[DW_LNS_set_isa] = 1
include_directories[  1] = "src"
file_names[  1]:
           name: "lib.rs"
      dir_index: 1
       mod_time: 0x00000000
         length: 0x00000000

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000002      9      0      1   0             0  is_stmt
0x0000000000000003     10      2      1   0             0  is_stmt prologue_end
0x0000000000000004     10      2      1   0             0  is_stmt end_sequence

mstange@Markuss-MacBook-Pro-2

@mstange
Copy link

mstange commented Aug 3, 2022

I can reproduce it with 1.48.0! So it looks like this got indeed fixed.

Output with 1.48.0:

[...]
Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000      4      0      1   0             0  is_stmt
0x0000000000000001      5      5      1   0             0  is_stmt prologue_end
0x0000000000000005      0      5      1   0             0 
0x0000000000000007      0      5      1   0             0  end_sequence
0x0000000000000002      9      0      1   0             0  is_stmt
0x0000000000000003     10      2      1   0             0  is_stmt prologue_end
0x0000000000000004     10      2      1   0             0  is_stmt end_sequence

@mitsuhiko
Copy link
Contributor Author

I wonder if it makes sense to add a regression test to make sure it does not happen again.

@wesleywiser wesleywiser added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants