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.
