Previously, the same file could be used across diagnostic options but
the file would be silently overwritten by the whichever option gets
handled last.
Details
- Reviewers
MaskRay - Commits
- rG67a212af4c24: [ELF] Make subsequent opens to auxiliary files append
Diff Detail
Event Timeline
I wonder whether this behavior is conventional? CC some folks to get some opinions.
@arichardson @ikudrin @smeenai @peter.smith
Note, if we use - as the output (stdout), they actually get appended --print-archive-stats=- --why-extract=-. In this case, supporting this seems fine.
lld/ELF/Config.h | ||
---|---|---|
468 | I wonder whether openAuxiliaryFile is more appropriate. The file type has a wide ranges including non-diagnostic use cases. | |
lld/test/ELF/diagnostic-options.test | ||
2 | This creates a file in the current directory which is not allowed in some cases, e.g. Google's internal lit runner. | |
3 | You can just use /dev/null as the only input file. |
We don't use this ourselves, but in general, appending seems like a much friendlier behavior than overwriting in this case. Do we need to be concerned about any simultaneous attempted writes to the same file though?
FWIW Arm's proprietary linker armlink puts out all diagnostics on one stream under append which includes the map file. It works well although we didn't have to contend with multiple threads interleaving the output.
It looks like the current cases are all in the single threaded path so this shouldn't be a problem.
One possibility that could be worth doing if we can detect that files share the same file is to put some extra line breaks or a header to distinguish between diagnostics. That may not be worth the complexity though.
One possibility that could be worth doing if we can detect that files share the same file is to put some extra line breaks or a header to distinguish between diagnostics. That may not be worth the complexity though.
The --cref output adds a newline, but does it so unconditionally, so --cref without -Map will print a newline followed by the rest of the output to stdout. Regarding the complexity, because raw_fd_ostream is not copyable/movable I think openAuxiliaryFile would need to first create the raw_fd_ostream, write the newline, then create it again to for return elision. I do think that I don't feel strongly either way, so I'll defer to what others think
This variable and the subject haven't been updated.