On Mon, Jan 03, 2022 at 12:48:05AM +1000, Allan McRae wrote:
On 3/1/22 00:29, Xiretza wrote:
On 02/01/2022 15.24, Allan McRae wrote:
On 3/1/22 00:20, Allan McRae wrote:
Add -n.
No change.
For a better example, here is my testing code:
source_files() { dbgsrcdir="${DBGSRCDIR:-/usr/src/debug}" local dbgsrclist="$(mktemp "${startdir}/dbgsrclist.${binary##*/}.XXXXXXXXX")" echo $1 >> $startdir/dbginfo echo sha256sum-orig: $(sha256sum $1) >> $startdir/dbginfo LANG=C debugedit -n -b "${srcdir}" -d "${dbgsrcdir}" -l "${dbgsrclist}" "$1" > /dev/null sort -zu "${dbgsrclist}" | tr '\0' '\n' sort -zu "${dbgsrclist}" | tr '\0' '\n' >> $startdir/dbginfo echo sha256sum-after: $(sha256sum $1) >> $startdir/dbginfo rm -f "$dbgsrclist" }
and a snippet of the output:
./usr/bin/vercmp sha256sum-orig: 844e2a18277df5d46544fc977a028b02b58d642bc9754d7d9868197d23f42407 ./usr/bin/vercmp pacman/builddir/<artificial> pacman/builddir/<built-in> pacman/lib/libalpm/version.c pacman/src/util/vercmp.c sha256sum-after: 844e2a18277df5d46544fc977a028b02b58d642bc9754d7d9868197d23f42407 ./usr/bin/vercmp
Is it possible that there are simply no source file entries referencing $srcdir (because -fdebug-prefix-map is working as expected)? As I said, if that's the case, the binary is not modified because there are no occurrences of $srcdir to be rewritten to $dbgsrcdir.
That is possible - I mostly tested packages I know obey CFLAGS. Saying that, any change would be a good thing, or else those source files placed in ${dbgsrcdir} are kindof useless! So I'm happy to have this rewrite paths - we are not regenerating the build-id, so I'm assuming this does not cause package reproducibility issues...
Also, I get a very different list of files with and without -b/-d. Without using them I get a lot of system files. With, I just get the package source files.
A
Xiretza is correct. It will rewrite the Go binaries and add correct paths since we do not have a prefix-map option in the Go compiler. However it won't change anything that utilizies prefix-map correctly. There might be a catch here, but I haven't found it. -- Morten Linderud PGP: 9C02FF419FECBE16