ld64’s implementation of -object_path_lto saves the object file
names according to module ID. I.e. a file like 123.arm64.thinlto.o
corresponds to module 123. We have a script internally that relies on
this behavior.
LLD, on the other hand, labels these object files using the task number.
The task number appears to correspond to module ID + 1. Task 0 is used
for the (typically empty) combined LTO module. I believe this is the same scheme that LLD-ELF and LLD-COFF use for their implementation of --save-temps.
While I could certainly update our internal script to handle this, it seems that
following ld64’s output a bit more closely could help other people adopt
LLD more smoothly. Then again this is kind of an edge case, and possibly
no one else actually relies on this behavior.
Either way, what I want to know is if the correspondence between task
number and module ID is guaranteed to hold. If it does, maybe we should come up with a better way for users of the LTO backend to obtain the module ID; right now the AddStream function only receives the task number, and subtracting 1 from that to obtain the module ID feels kind of janky.