[PATCH 1/1] strip: Use debugedit instead of AWK to parse source files

[Allan McRae]

On 3/1/22 01:00, Xiretza wrote:
> On 02/01/2022 15.48, 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...
> 
> Makes sense, I can't think of any issues this would cause either - the 
> source file paths have to be deterministic anyway, applying a 
> deterministic transform on top won't change that.
> 
> Still, having a function called "source_files" actually modify the 
> passed binary deserves a comment, I think.
> 
Alternatively, happy for the function to be renamed something better.

A