Re: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip

On 29/11/2025 14:40, ASSI via Cygwin-apps wrote:
> Jon Turney via Cygwin-apps writes:
>> If the executable is hardlinked under multiple names, then parallel
>> instances of __prestrip_one are going to extract debug info to
>> multiple .dbg files, then fight over which one gets to set the
>> debuglink to point at one of those .dbg files.
>>
>> This occurs with the 'bvi' package, where bview and bvedit are
>> hardlinked to bvi.
> 
> Ugh…
> 
>> Now, maybe this already doing the wrong thing in the old,
>> non-parallelized code as well (or maybe it worked OK, because if a
>> debuglink was already present, we don't try to strip the file again
>> the subsequent times we process it?)
> 
> Whatever it does it from your description it would seem to mean that you
> can then debug one of the hardlinked executables, but not the other?

No, I think that should work fine, because the debuglink points to a 
filename.

gdb is capable of debugging A when the debuglink points to B.dbg.


The problem is we have a process which goes something like:

- check if F has an existing debuglink section, if so stop
- otherwise, extract symbols from F to F.dbg
- strip symbols from F
- add a debuglink section to F pointing to F.dbg

... which is run in parallel for F=(A, B, C) (which are all hardlinks 
for the same file).


So we end up with {A,B,C}.dbg, which are all the same, and only one of 
them is actually used.

Except sometimes one of the processes loses the race, so doesn't do 
anything because the debuglink already exists.

(which results in a non-deterministic set of files in the output package 
archive, which makes the test I've added fail...)

>> So, idk how this should be written correctly? Make sure we only
>> process each inode once?
> 
> Create a .dbg for one and then hardlink the others, it would seem.
> Which means that we'd need to figure out which of the files that are
> coming in are linked to each other and filter out the duplicates I
> think.