The hack for #291 breaks reading DWARF line info from .o files

[glandium]

Environment

Steps to Reproduce

1. cargo new testcase
2. cd testcase

[package]
name = "testcase"
version = "0.1.0"
edition = "2021"
[dependencies]
symbolic-debuginfo = "8"
EOF

cat > src/main.rs <<EOF
use std::io::Read;

fn main() {
    for file in std::env::args().skip(1) {
        let mut data = Vec::new();
        std::fs::File::open(file)
            .unwrap()
            .read_to_end(&mut data)
            .unwrap();
        for f in symbolic_debuginfo::Object::parse(&data)
            .unwrap()
            .debug_session()
            .unwrap()
            .functions()
        {
            println!("{:#?}", f);
        }
    }
}
EOF

5. curl -Lo mac-normal.o https://github.com/mozilla/fix-stacks/blob/master/tests/mac-normal.o?raw=true
6. cargo run mac-normal.o

Expected Result

Two Functions printed, both with LineInfos.

Actual Result

Only one of them has LineInfo.

Reverting the hack for #291 (c13ac5c) fixes it.

What's worth noting is that while reading DWARF info from mach-o objects generally works except for this, DWARF info from ELF objects is even more broken:

cat > foo.c <<EOF
int foo() {
       	return 42;
}

int bar() {
       	return 42;
}
EOF
gcc -o foo.o -c foo.c -g
cargo run foo.o

displays only one Function, without LineInfos.

cat > bar.c <<EOF
int foo() {
       	return 42;
}

void bar() {
}
EOF
gcc -o bar.o -c bar.c -g
cargo run bar.o

displays two Functions, without LineInfos, both with the name foo.

I presume this is because in the former case, both functions have the same (address, size).

[glandium]

I presume this is because in the former case, both functions have the same (address, size).

It is worth noting that dwarfdump shows different addresses for the functions, but not the info the testcase prints.

[loewenheim]

We don't know when we'll get around to fixing this. Can you run off a fork in the meantime?

[glandium]

What's your time frame? It's been busted on our end since we upgraded to version 8, which was almost a year ago, so a few weeks is not going to make a huge difference.

[loewenheim]

It's probably gonna take us a while.

[mstange]

Maybe one option would be to allow zero addresses for relocatable objects, similar to what's done here:

symbolic/symbolic-debuginfo/src/dwarf.rs

Lines 487 to 489 in 6711360

	// not contain any code that can be executed. Special case relocatable objects, as here the
	// range information has not been written yet and all units look like this.
	if info.kind != ObjectKind::Relocatable

[jernejstrasner]

This issue is stale. Closing. Please reopen if necessary.

[glandium]

This still is an issue, but there is no option to reopen.