User Details
- User Since
- Jan 31 2017, 4:46 PM (277 w, 3 d)
Yesterday
Apr 20 2022
Lgtm
Apr 19 2022
Mar 29 2022
rebased
Mar 28 2022
Mar 25 2022
Mar 4 2022
Feb 18 2022
Feb 17 2022
Usually when you have these kinds of things they're called include and exclude.
I don't think we have any known use cases for include, just for exclude so it would be sufficient to start with just that feature.
Feb 16 2022
LGTM but Haowei should give the final say.
Feb 11 2022
lgtm except for possible susceptibility to invalid DT_STRSZ values.
Perhaps there should be a test case for a corrupted PT_DYNAMIC region.
Feb 7 2022
Feb 2 2022
Jan 26 2022
lgtm
Jan 25 2022
I think in fact the proper thing for this case is to just use a single operand "+t" to directly indicate that the one operand is both input and output. I'm not sure that "=&t" and "0" will behave any different, but this seems to be exactly what "+" is for.
Jan 24 2022
Jan 21 2022
lgtm
Jan 18 2022
Please understand that InstrProfData.inc is now a public installed header file in the compiler-rt installation, at <profile/InstrProfData.inc>. So *any* changes to this file have a quite high standard of compatibility concern.
Jan 14 2022
Jan 11 2022
lgtm
Jan 10 2022
Ping. This is very similar to the other change I landed recently. It needs approval from a libc++ maintainer.
Thanks.
Jan 7 2022
LGTM modulo the fallback behaviors as mentioned below. But I'll leave the approval to those who have done the review for this specific codebase more generally, since I'm not sure on all the points of LLVM style or what library features are available or best to use.
Jan 6 2022
Jan 4 2022
Jan 2 2022
Dec 28 2021
Just the fact that any follow-up changes were required is clear testament to the fact that this was never a change that was appropriate to commit without community review and approval as all LLVM changes require. Regardless of the technical details, nontrivial changes, especially ones affecting the user-visible semantics, simply should not be committed without proper review. Resistance to reverting unreviewed changes is simply hostile to the community's established standards and code of conduct and frankly does not merit further technical discussion. The appropriate forum for technical discussion is in review of changes such as these *before* they are committed. The appropriate action right now is to revert all the changes that were not properly reviewed and changed behavior in ways that reviewers have not yet had the opportunity to discuss. Once the damage done has been recovered, then it's appropriate to propose the changes you wanted made and allow proper review and discussion about the semantics being changed.
Dec 3 2021
This feature seems like a good addition. I'm wondering about the interactions with other switches and if it might make sense to rearchitect some of the CLI API here for the more arcane corners. Maybe it's already orthogonal enough, but I'm not sure. I'm thinking in particular about the various --strip-* options. Perhaps it's the case that all such variations apply only to text IFS output? I'm also wondering if there might be use cases for multiple different kinds of IFS output (i.e. different sets of stripping / arch options). Come to think of it, we could even have uses for multiple ELF stub outputs from the same IFS input with different switches (e.g. arch). So perhaps it makes sense to go in a direction where each output file is separately described with both its format (IFS vs ELF) and its format options (stripping, arch, etc), and there can be any number of such output files in whatever combination. I'm not sure exactly what a CLI syntax for that would look like. Another possibility that might fit well for build system integration is to accept a complex output specification in JSON either as a command-line switch value or from a file.
Nov 30 2021
lgtm, but we should be sure to advise users that their debugging tools may need build adjustments to ensure they support the compressed formats.
lgtm, but we should be sure to advise users who may need to use -gdwarf-4 explicitly if their debugging tools become unhappy.
renamed callback
Nov 29 2021
Nov 22 2021
second copy of InstrProfData.inc
Use a DenseMap rather than instruction name to match bias load.
Nov 21 2021
Nov 16 2021
Nov 10 2021
Reordered the switches.
reordered switches
rebased
Nov 3 2021
Sep 23 2021
Aug 27 2021
add more casts
Aug 26 2021
The intent is to sanity-check for garbage header fields. The uncompressed size field is one that you can only warn about heuristically like this I guess. But you can do a definitive test on the CompressedSize field to ensure that it isn't larger than the actual size of the data available. There's no need to even worry about whether UncompressedSize is valid if CompressedSize is clearly invalid.
Aug 25 2021
lgtm
Aug 23 2021
Aug 12 2021
Aug 6 2021
Aug 5 2021
Jul 27 2021
lgtm
lgtm
lgtm
Jul 23 2021
lgtm
Jul 20 2021
lgtm