Using -ffile-prefix-map with objdump -S

Question

In order to get reproducible builds, we use the --ffile-prefix-map=/path/to/src=SRC --file-prefix-map=/path/to/lib=LIB option when compiling. And similarly, for gdb I can set substitute-path SRC=/path/to/src etc.

However, I cannot figure out how to do a similar thing with objdump -S. I can work around it with a small maze of symlinks, but I don't understand the --prefix option to objdump, or know if it is the right thing to use. I tried --prefix-strip=1 --prefix=/path/to/src but it did not seem to do what I expected (well, it didn't manage to include any source code!)

Is there any way to do this?

Answer 1

After a bit of experimentation and a quick insight into the source code of the objdump utility, just to make sure I got it all right from objdump(1), I managed to achieve the desired outcome. This is probably going to be puzzling because I did nothing special, yet it all worked out as expected.

First, I created a simple "Hello, world!" program in a file named test.c:

#include <stdio.h>

int main(int argc, char** argv) {
    printf("Hello, world!\n");
}

Got it compiled using the following command:

gcc -Wall -ggdb -ffile-prefix-map=/path/to/cwd=/src test.c -o test

Using strings test | grep /src verified that /src actually got into the resulting test binary, so it was time to get objdump -S to find the source code, using the following command:

objdump -S --prefix=/path/to/cwd --prefix-strip=1 test

Here's an excerpt from the produced output, which shows the desired source code fragments in the disassembled code:

0000000000000744 <main>:
#include <stdio.h>

int main(int argc, char** argv) {
 744:   a9be7bfd    stp x29, x30, [sp, #-32]!
 748:   910003fd    mov x29, sp
 74c:   b9001fe0    str w0, [sp, #28]
 750:   f9000be1    str x1, [sp, #16]
    printf("Hello, world!\n");
 754:   90000000    adrp    x0, 0 <__abi_tag-0x278>
 758:   91204000    add x0, x0, #0x810
 75c:   97ffffb1    bl  620 <puts@plt>
 760:   52800000    mov w0, #0x0                    // #0
}
 764:   a8c27bfd    ldp x29, x30, [sp], #32
 768:   d65f03c0    ret
 76c:   d503201f    nop

Thus, it must be that something isn't exactly right in the environment you're using. Perhaps it would be good to try reproducing a simple example like this one first, to see will it work as expected. I hope this helps.

See also this question for an additional insight.