zig icon indicating copy to clipboard operation
zig copied to clipboard

llvm-objdump reports "invalid section index" on self-hosted linked ELF files

Open andrewrk opened this issue 4 years ago • 4 comments

Zig Version

0.10.0-dev.286+e23f7c01e

Steps to Reproduce

test.zig:

pub fn main() void {}

Have a test binary already on disk, from a prior compilation. I'm not sure yet exactly how to produce this to make the problem happen.

$ ./zig build-exe -fno-stage1 -target arm-linux test.zig
$ llvm-objdump -d test

test:	file format elf32-littlearm
/home/andy/local/llvm13-release/bin/llvm-objdump: error: 'test': invalid section index: 32

Expected Behavior

Expected objdump to understand the ELF file and print a disassembly.

Actual Behavior

error: 'test': invalid section index: 32

andrewrk avatar Jan 15 '22 17:01 andrewrk

Hmm, I can't seem to reproduce this. llvm-objdump works fine for me.

joachimschmidt557 avatar Jan 15 '22 18:01 joachimschmidt557

Ah ok that gave me a clue. I don't have perfect reproduction steps yet but I know that it has to do with when the destination ELF file already exists on disk, the incremental compilation is not properly reconciling.

andrewrk avatar Jan 15 '22 18:01 andrewrk

Yeah, my executable was non-existent before compilation so incremental compilation didn't kick in.

joachimschmidt557 avatar Jan 15 '22 18:01 joachimschmidt557

Yeah, my executable was non-existent before compilation so incremental compilation didn't kick in.

I know this is an old thread, however, I just wanted to point out here that we currently do not deserialize existing metadata from existing binary. Incremental compilation/linking only kicks in if we run zig build-exe -watch explicitly. Having said, when opening file for writing we do not truncate it in incremental/self-hosted context so that's probably the root cause.

kubkon avatar Aug 16 '22 20:08 kubkon