zig objcopy produces incorrect Extended Linear Address in hex files

[ekoeppen]

Zig Version

0.11.0-dev.1183+2b9478ce1

Steps to Reproduce and Observed Behavior

Compiling the STM32F4 blinky example here: https://github.com/ZigEmbeddedGroup/microzig-examples/tree/blinky-stm32, the ELF file has a text segment at 0x08000000, but the hex file creates the record :020000042D00F2, which has 0x2d00 as the extended load address. Additionally, the checksum for that record is incorrect.

Expected Behavior

The record should be :020000040800F2.

[ekoeppen]

Short reproducer for objcopy.zig:

test "HexWriter" {
    const record = HexWriter.Record.Address(0x0800_0000);
    const payload = record.getPayloadBytes();
    const sum = record.checksum();
    try std.testing.expect(payload.len == 2);
    try std.testing.expect(payload[0] == 8);
    try std.testing.expect(payload[1] == 0);
    try std.testing.expect(sum == 0xf2);
}

[ekoeppen]

It looks like the data pointed to by payload is going out of scope somewhere. Getting the payload bytes again after the getting checksum produces correct data.

[Vexu]

getPayloadBytes is returning a pointer to stack local, changing it's signature to fn getPayloadBytes(self: *const Record) []const u8 makes the test pass.

[ekoeppen]

Yep, that was it, the test works and also the hex file looks good now - kiitos!