This is an archive of the discontinued LLVM Phabricator instance.

Discussion: Darwin Sanitizers Stable ABI
ClosedPublic

Authored by rsundahl on Feb 9 2023, 12:45 PM.

Details

Summary

Darwin Sanitizers Stable ABI

We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and novel approaches to ASan for developers, researchers and others.

Details

Rather than adding a lot of conditional code to the LLVM instrumentation phase, which would incur excessive complexity and maintenance cost of adding conditional code into all places that emit a runtime call, we propose a “shim” layer which will map the unstable ABI to the stable ABI:

  • A static library (.a library) shim that maps the existing ASan ABI to a generalized, smaller and stable ABI. The library would implement the __asan functions and call into the new ABI. For example:
    • void __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); }
    • void __asan_load2(uptr p) { __asan_abi_loadn(p, 2, true); }
    • void __asan_noabort_load16(uptr p) { __asan_abi_loadn(p, 16, false); }
    • void __asan_poison_cxx_array_cookie(uptr p) { __asan_abi_pac(p); }
  • This “shim” library would only be used by people who opt in: A compilation flag in the Clang driver will be used to gate the use of the stable ABI workflow.
  • Utilize the existing ability for the ASan instrumentation to prefer runtime calls instead of inlined direct shadow memory accesses.
  • Pursue (under the new driver flag) a better separation of abstraction and implementation with:
    • LLVM instrumentation: Calling out for all poisoning, checking and unpoisoning.
    • Runtime: Implementing the stable ABI and being responsible of implementation details of the shadow memory.

Maintenance

Our aim is that the maintenance burden on the sanitizer developer community be negligible. Stable ABI tests will always pass for non-Darwin platforms. Changes to the existing ABI which would require a change to the shim have been infrequent as the ASan ABI is already relatively stable. Rarely, a change that impacts the contract between LLVM and the shim will occur. Among such foreseeable changes are: 1) changes to a function signature, 2) additions of new functions, or 3) deprecation of an existing function. Following are some examples of reasonable responses to those changes:

  • Example: An existing ABI function is changed to return the input parameter on success or NULL on failure. In this scenario, a reasonable change to the shim would be to modify the function signature appropriately and to simply guess at a common-sense implementation.
    • uptr __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); return p; }
  • Example: An additional function is added for performance reasons. It has a very similar function signature to other similarly named functions and logically is an extension of that same pattern. In this case it would make sense to apply the same logic as the existing entry points:
    • void __asan_load128(uptr p) { __asan_abi_loadn(p, 128, true); }
  • Example: An entry point is added to the existing ABI for which there is no obvious stable ABI implementation: In this case, doing nothing in a no-op stub would be acceptable, assuming existing features of ASan can still work without an actual implementation of this new function.
    • void __asan_prefetch(uptr p) { }
  • Example: An entrypoint in the existing ABI is deprecated and/or deleted:
    • (Delete the entrypoint from the shim.)

We’re looking for buy-in for this level of support.

(Note: Upon acceptance of the general concepts herein, we will add a controlling clang flag, cmake integration, contract for the stable ABI, and the appropriate test infrastructure.)

Diff Detail

Event Timeline

rsundahl created this revision.Feb 9 2023, 12:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 9 2023, 12:45 PM
Herald added a subscriber: Enna1. · View Herald Transcript
rsundahl requested review of this revision.Feb 9 2023, 12:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 9 2023, 12:45 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
rsundahl retitled this revision from Discussion: to Discussion: Darwin Sanitizers Stable ABI.Feb 9 2023, 12:48 PM
wrotki added a subscriber: wrotki.Feb 9 2023, 1:20 PM

I think this should generally work.

It sounds like you are adding a lot of overhead in the stable-abi compilation mode - not only all load/store checking is outlined, but it also goes through 2 levels of wrappers. It would be nice if at least the caller-side shim was inlined or LTO-inlined.

rsundahl edited the summary of this revision. (Show Details)Feb 9 2023, 2:06 PM

I think this should generally work.

It sounds like you are adding a lot of overhead in the stable-abi compilation mode - not only all load/store checking is outlined, but it also goes through 2 levels of wrappers. It would be nice if at least the caller-side shim was inlined or LTO-inlined.

Thank you @eugenis. We thought we'd start with a naive implementation like this and when we have an instrumented (but essentially no-op) stack, measure the fixed overhead to see what we need and how best to get there.

rsundahl edited the summary of this revision. (Show Details)Feb 9 2023, 2:28 PM
MaskRay added a comment.EditedFeb 14 2023, 12:41 PM

Hi! For a discussion it's norm to start a topic on Discourse (https://discourse.llvm.org/c/runtimes/64). You can link the patch to it.
In other subprojects of llvm-project, an in-tree documentation is typically in llvm-project/*/docs/, not in a directory like lib/*/

For the technical side, I think asan_* functions names collide with the user namespace. It'd be good to use reserved identifiers.

Based on previous discussions about this topic,

Do you have links to previous discussions about this topic?

compiler-rt/lib/stable_abi/README.txt
1 ↗(On Diff #496216)

Keep just README.md and delete this duplicated copy?

compiler-rt/lib/stable_abi/stable_abi_shim.c
660 ↗(On Diff #496216)

Extra space before the type. This applies to everything below.

rsundahl updated this revision to Diff 498939.Feb 20 2023, 12:55 PM

Addressed various suggestions from review.

rsundahl updated this revision to Diff 498941.Feb 20 2023, 12:59 PM

Missed namespace change for stable abi (sabi)

rsundahl updated this revision to Diff 498942.Feb 20 2023, 1:06 PM

Namespace misses.

rsundahl edited the summary of this revision. (Show Details)Feb 20 2023, 1:08 PM
rsundahl updated this revision to Diff 498943.Feb 20 2023, 1:12 PM

Including stable_abi_shim.c in the rename.

rsundahl marked an inline comment as done.Feb 20 2023, 1:15 PM
rsundahl marked an inline comment as done.

Hi! For a discussion it's norm to start a topic on Discourse (https://discourse.llvm.org/c/runtimes/64). You can link the patch to it.
In other subprojects of llvm-project, an in-tree documentation is typically in llvm-project/*/docs/, not in a directory like lib/*/

Thank you @MaskRay! I think mainly that we didn't want stimulate a broader discussion for the narrow scope of our use case, at least not yet. Rather, we are looking for support from yourself, @eugenis @kcc, @vitalybuka and code owners in support of our specific situation.

For the technical side, I think asan_* functions names collide with the user namespace. It'd be good to use reserved identifiers.
I used __asabi_ as a namespace for the new entry points.

Based on previous discussions about this topic,

Do you have links to previous discussions about this topic?

This was from group memory and not from a specific discussion.

rsundahl updated this revision to Diff 500324.Feb 24 2023, 4:02 PM

Full adoption of rename asan_stable_abi -> asabi.

rsundahl updated this revision to Diff 501308.Feb 28 2023, 3:22 PM

Moved and renamed files using asabi namespace. Added CMake scaffolding.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 28 2023, 3:22 PM

Usually freezing signatures is not a big concern, we can agree to preserve existing functions.
The stuff like ASanStackFrameLayout is the concern. compiler and runtime must agree on data layout. The same for global.

rsundahl added a comment.EditedFeb 28 2023, 4:16 PM

Hi! For a discussion it's norm to start a topic on Discourse (https://discourse.llvm.org/c/runtimes/64). You can link the patch to it.

Now at: https://discourse.llvm.org/t/darwin-sanitizers-stable-abi/68834
cc: @MaskRay:

thetruestblue added inline comments.Feb 28 2023, 4:38 PM
compiler-rt/cmake/config-ix.cmake
734

This was an artifact leftover from some of my cmake changes. This line needs to be removed..

Usually freezing signatures is not a big concern, we can agree to preserve existing functions.
The stuff like ASanStackFrameLayout is the concern. compiler and runtime must agree on data layout. The same for global.

Yes. Presently, the address sanitizer code generator is very aware of the stack frame layout and how it will be poisoned up to and including the values to be stored in the shadow memory. I don't think that the runtime actually shares ASanStackFrameLayout at the moment but certainly would be supportive if under this proposed flag (where everything gets outlined), we actually passed some canonicalized/serialized ASanStackFrameLayout object to the runtime where it would be free to implement as appropriate. We're not proposing this kind of change at this time but may be worth doing in some future effort to separate instrumentation from implementation. (Similar arguments apply under this flag for globals).

rsundahl updated this revision to Diff 501357.Feb 28 2023, 7:05 PM

Deleted extraneous line from compiler-rt/cmake/config-ix.cmake

rsundahl marked an inline comment as done.Feb 28 2023, 7:07 PM

Currently & ideally asabi_shim.h is unnecessary -- but we hope to use only headers from ../asan/

@kcc Any takes from you on this?

@kcc @eugenis @MaskRay @vitalybuka Ok to go with this? All new functionality is under the added flag so not expecting any surprises.

@kcc @eugenis @MaskRay @vitalybuka Ok to go with this? All new functionality is under the added flag so not expecting any surprises.

I don't have reasons to block this.

clang/include/clang/Driver/Options.td
1794

how likely you will need thus for other sanitizers in future
should this be rather -fsanitize-stable-abi which is ignore for now for other sanitizers?

compiler-rt/lib/asabi/CMakeLists.txt
2 ↗(On Diff #501358)

does it need to be asabi?
maybe better asan_abi, files and macro?

rsundahl updated this revision to Diff 515559.Apr 20 2023, 7:09 PM

Rename fsanitize_address_stable_abi to fsanitize_stable_abi

rsundahl marked an inline comment as done.Apr 20 2023, 8:11 PM
rsundahl added inline comments.
clang/include/clang/Driver/Options.td
1794

Thanks @vitalybuka. I agree and made this change. For now I still only consume the flag if sanitizer=address so that we continue to get the unused option warning in the other cases and left the test for that warning intact.

rsundahl marked an inline comment as done.Apr 20 2023, 8:15 PM
rsundahl added inline comments.Apr 20 2023, 8:24 PM
compiler-rt/lib/asabi/CMakeLists.txt
2 ↗(On Diff #501358)

The idea is that "asabi" replaces "asan" (where the "s" stands in for "stable"), but I understand the distraction of sounding like a hot condiment! I wonder what you think of "asan_stable" (over "asan_stable_abi" or "asan_abi" as you suggest). I am more at ease with emphasizing the "stable" over the "abi" since both "asan" and "asan_stable" share ABI-ness without calling it out. This might read and organize a bit more naturally with what we already have. Thanks for the input.

rsundahl updated this revision to Diff 518552.May 1 2023, 1:40 PM

Rename asabi->asan_abi

rsundahl edited the summary of this revision. (Show Details)May 1 2023, 1:43 PM
rsundahl edited the summary of this revision. (Show Details)
rsundahl marked an inline comment as done.May 1 2023, 1:52 PM

@kcc @eugenis @MaskRay @vitalybuka Ok to go with this? All new functionality is under the added flag so not expecting any surprises. Rename asabi->asan_abi as suggested.

compiler-rt/lib/asabi/CMakeLists.txt
2 ↗(On Diff #501358)

Changed "asabi" namespace to "asan_abi". Applied to files, directories and contents.

I'm fine with it in general. Is asan_abi.cpp meant as a temporary stub? It's not even link anywhere in the current version.

vitalybuka accepted this revision.May 1 2023, 2:37 PM
vitalybuka added 2 blocking reviewer(s): eugenis, MaskRay.

@kcc @eugenis @MaskRay @vitalybuka Ok to go with this? All new functionality is under the added flag so not expecting any surprises. Rename asabi->asan_abi as suggested.

Thanks, asan_abi LGTM.

I don't have good reasons to object that patch, but I suspect it's sub-optimal. But we may get a valuable expirience.

Rather than adding a lot of conditional code to the LLVM instrumentation phase

We do this for hwasan for Android, and to some extent msan for Chromium. @eugenis maybe can share more info.

Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms.

I guess we just have no way to enforce that. A couple of buildbots with "stable clang" + "HEAD runtime" and "HEAD clang" + "stable runtime" which do some non-tivial build, e.g. clang bootstrap can enforce that. We can at list to enforce default set of flags.

Small insignificant note from me: When this lands, please be sure to add me as co-author.
https://github.blog/2018-01-29-commit-together-with-co-authors/

I'm fine with it in general. Is asan_abi.cpp meant as a temporary stub? It's not even link anywhere in the current version.

Right, we should be using it... We will add a test that compiles and links to it as affirmation that we have covered all of the entrypoints that ASan generates. It's also the case that asan_abi_shim.h is redundant since asan_abi_shim.cpp now gets its declarations from ../asan/asan_interface_internal.h which is of course the source of truth for what the shim should be implementing. We will remove that as well and update. Thanks.

Small insignificant note from me: When this lands, please be sure to add me as co-author.
https://github.blog/2018-01-29-commit-together-with-co-authors/

I've not seen this before @thetruestblue! I certainly will do so!

rsundahl updated this revision to Diff 521479.May 11 2023, 3:34 PM

Added testing. Removed asan_abi_shim.h.

rsundahl updated this revision to Diff 521482.May 11 2023, 3:43 PM

Fixed nits (missing newlines at end of files)

I'm fine with it in general. Is asan_abi.cpp meant as a temporary stub? It's not even link anywhere in the current version.

We now use it during testing to close the loop on the question of whether the file is "complete" in the sense that it satisfies the minimal "no-op" implementation of the abi. We also moved from having a hand-curated include file to using the actual interface file which should be the root truth for what needs to be in there. We discovered a few additional functions that were in asan_interface.h but aren't strictly part of the interface between the instrumentation and the runtime but rather are used intra-runtime. Some other routines living in asan_interface.h are really documented "helper" functions. Maybe these should be aggregated somewhere else and/or under a different namespace. For now we ignore those entrypoints by listing them in compiler-rt/lib/asan_abi/darwin_exclude_symbols.inc

vitalybuka added inline comments.May 11 2023, 4:17 PM
compiler-rt/lib/asan_abi/asan_abi_shim.cpp
63

static_assert

MaskRay added inline comments.May 11 2023, 5:22 PM
compiler-rt/lib/asan_abi/asan_abi_shim.cpp
15

Comments are usually a complete sentence with a period. There are exceptions, but a "Globals" needs elaboration to make it better understandable by a reader.

17

2-space indentation, here and throughout.

42

C++ prefers () instead of (void).

487

You may apply clang-format, which may turn this into (void *)0, but nullptr likely works better.

compiler-rt/test/asan_abi/TestCases/Darwin/llvm_interface_symbols.cpp
2

excess spaces

-O2 ... -O0?

5

One blank line suffices.

10

We generally prefer llvm counterparts to the system binary utilities. Use llvm-nm

16

unneeded ^//$ lines, here and throughout.

17

Does Darwin sed accept ; to combine multiple -e into one -e with ;?

22

2-space indentation for | continuation lines as well

27

sort %t.imports. See Useless use of cat

compiler-rt/test/asan_abi/TestCases/linkstaticlibrary.cpp
2

-O2 ... -O0

I'm fine with it in general. Is asan_abi.cpp meant as a temporary stub? It's not even link anywhere in the current version.

We now use it during testing to close the loop on the question of whether the file is "complete" in the sense that it satisfies the minimal "no-op" implementation of the abi. We also moved from having a hand-curated include file to using the actual interface file which should be the root truth for what needs to be in there. We discovered a few additional functions that were in asan_interface.h but aren't strictly part of the interface between the instrumentation and the runtime but rather are used intra-runtime. Some other routines living in asan_interface.h are really documented "helper" functions. Maybe these should be aggregated somewhere else and/or under a different namespace. For now we ignore those entrypoints by listing them in compiler-rt/lib/asan_abi/darwin_exclude_symbols.inc

How is compiler-rt/lib/asan_abi/darwin_exclude_symbols.inc used in the upstream and downstream build system?
In this patch this file is only used by one test?

clang/include/clang/Driver/Options.td
1794

See BooleanFFlag. Some existing sanitizer options are not written with the best practice.

If -fno-sanitize-stable-abi is the default, there is usually no need to have a duplicate help message Disable .... Documenting the non-default boolean option suffices.

clang/lib/Driver/SanitizerArgs.cpp
917

Existing code unnecessarily reads the previous value (false) of the variable. No need to copy that for new code.

1289

Optional nit: I added -mllvm= as an alias in D143325. You can use -mllvm=-asan-instrumentation-with-call-threshold=0 to decrease the number/length of cc1 options.

Add some comments before if (StableABI) { why the two cl::opt options are specified.

clang/test/Driver/fsanitize.c
266 ↗(On Diff #521482)

I think the tests should go to a new file fsanitize-stable-abi.c. The checks are different enough from the rest of fsanitize.c (which can be split).

269 ↗(On Diff #521482)

I presume that you want to test the positive forms with Darwin triples like arm64-apple-darwin?

We can even argue that the option should lead to an error for non-Darwin triples.

compiler-rt/docs/asan_abi.md
1 ↗(On Diff #521482)

The existing compiler-rt/docs docs use .rst. Better to use .rst to not introduce more than one format for one subproject.

.rst is used much more than .md in llvm-project anyway.

compiler-rt/lib/asan_abi/asan_abi.h
14

use clang-format to sort the headers. I'd expect that stdbool and stddef are placed together for any sorting behavior.

16

add a blank line before extern "C" {

compiler-rt/test/asan_abi/lit.cfg.py
10

This workaround is unneeded. I sent D150410 to clean up other lit.cfg.py files.

21

is None is better.

84

!=

@kcc @eugenis @MaskRay @vitalybuka Ok to go with this? All new functionality is under the added flag so not expecting any surprises. Rename asabi->asan_abi as suggested.

Thanks, asan_abi LGTM.

I don't have good reasons to object that patch, but I suspect it's sub-optimal. But we may get a valuable expirience.

Rather than adding a lot of conditional code to the LLVM instrumentation phase

We do this for hwasan for Android, and to some extent msan for Chromium. @eugenis maybe can share more info.

Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms.

I guess we just have no way to enforce that. A couple of buildbots with "stable clang" + "HEAD runtime" and "HEAD clang" + "stable runtime" which do some non-tivial build, e.g. clang bootstrap can enforce that. We can at list to enforce default set of flags.

Very sorry for my belated response. I feel that I am not a decision maker, so I am waiting on the maintainers.
I do care about driver options (as a code owner) and sanitizer maintainability (my interest), though. I have left some comments and will be happy when they are resolved.

The documentation compiler-rt/docs/asan_abi.md probably needs more polishing. The current style is like seeking for RFC, not for something already in tree.

compiler-rt/docs/asan_abi.md
3 ↗(On Diff #521482)

The introductory paragraph is written in a style like the RFC, but not for the official documentation.
The official documentation should be written in a style that this has been accepted.
For sentences like maintenance costs, they can be moved to the Maintenance chapter.

I have an simplified introductory paragraph:

Some OSes like Darwin want to include the AddressSanitizer runtime by establishing a stable ASan ABI. lib/asan_abi contains a secondary stable ABI for our use and others in the community. This new ABI will have minimal impact on the community, prioritizing stability over performance.

Feel free to add more sentences if you feel too simplified.

Note that .rst uses two backsticks for what Markdown uses one backstick for.

7 ↗(On Diff #521482)

Similarly, words like "propose" are RFC-style wording, not for the official documentation. For the official documentation, you just say what this is.

14 ↗(On Diff #521482)

This “shim” library will only be used when -fsanitize-stable-abi is specified in the Clang driver.

thetruestblue added inline comments.May 11 2023, 8:12 PM
compiler-rt/test/asan_abi/lit.cfg.py
84

The thought here was to leave basic lit patterns in-tact to expand to other OSs if others want to in the future. But if there's no desire for that, it doesn't make a big difference to me.

rsundahl updated this revision to Diff 522417.May 15 2023, 8:20 PM

Applied suggestions from reviewers

Cleaned up options parsing
Moved test into stanalone file fsanitize-stable-abi.c
Changed target triple to arm64-apple-darwin
Changed documentation style from proposal to specification
Changed format of documentation form .md to .rst
Applied clang-format to entire diff
Removed extraneous spaces and lines
Expanded comments to sentences
Switched to static_assert()

rsundahl marked 22 inline comments as done.May 15 2023, 8:44 PM

Thank you for your review and thoughtful input @eugenis, @MaskRay and @vitalybuka. I think we're close to having everything incorporated. (@MaskRay, the doc files went from .md to .rst and I implemented all of your suggestions there.

clang/include/clang/Driver/Options.td
1794

(Not sure if this is exactly what you meant @MaskRay but I think it's close.)

clang/lib/Driver/SanitizerArgs.cpp
1289

I couldn't get this one to work. Did I do it wrong? (Couldn't find example in the code to go from.)

Tried:

if (StableABI) {
  CmdArgs.push_back("-mllvm=-asan-instrumentation-with-call-threshold=0");
  CmdArgs.push_back("-mllvm=-asan-max-inline-poisoning-size=0");
}

Got:

error: unknown argument: '-mllvm=-asan-instrumentation-with-call-threshold=0'
error: unknown argument: '-mllvm=-asan-max-inline-poisoning-size=0'
compiler-rt/lib/asan_abi/asan_abi_shim.cpp
42

These are actually "C'
Added:

extern "C" {
...
}
487

clang-format left this as-is. I suspect this is because I also added the extern "C" brackets.

compiler-rt/test/asan_abi/TestCases/Darwin/llvm_interface_symbols.cpp
17

I couldn't get the same behavior out of the intersection of GNU an BSD set. Tried hard in https://reviews.llvm.org/D138824 and landed with the -e's. iirc exactly what the problem was with semicolons, just that I was relieved when I found a format that worked for all the platforms.

27

Good point!

compiler-rt/test/asan_abi/lit.cfg.py
10

Wasn't actually used anyway but good to know!

84

I landed on just an else clause. Let me know if that's ok @thetruestblue.

rsundahl marked 8 inline comments as done.May 15 2023, 8:46 PM
rsundahl marked 4 inline comments as done.May 15 2023, 9:00 PM

Suggestions for compiler-rt/docs/asan_abi.md are captured in the successor file compiler-rt/docs/ASanABI.rst and marked complete.

rsundahl marked 2 inline comments as done.May 15 2023, 9:02 PM

Suggestions for compiler-rt/docs/asan_abi.md are captured in the successor file compiler-rt/docs/ASanABI.rst and marked complete.

rsundahl updated this revision to Diff 522452.May 15 2023, 11:31 PM

Missed one file in revert of combined -mllvm= change.

rsundahl updated this revision to Diff 522592.May 16 2023, 6:46 AM

Renamed darwin_exclude_symbols.inc asan_abi_tbd.txt.

This file contains the entrypoints that aren't strictly in the interface
between the instrumentation and the runtime but may still be part of a
public API that needs to have a home in Stable ABI. For now we acknowledge
them in the existing ABI and explicitly list them as TBD until we have a
complete story for how the shim deals with them.

MaskRay accepted this revision.May 16 2023, 10:33 AM

@MaskRay, thank you for your approval. @eugenis, you were added as a blocking reviewer by @vitalybuka. If you are still without objection, can we get your approval and merge? Thank you all for your input.

MaskRay added inline comments.May 17 2023, 7:26 PM
compiler-rt/docs/ASanABI.rst
30

How does the 2-space indentation render in the built HTML? It may look good, I ask just in case.

compiler-rt/lib/asan_abi/asan_abi.h
19

asan_abi.h is C++ only (extern "C" isn't allowed in C). (void) should be replaced with ().

compiler-rt/lib/asan_abi/asan_abi_shim.cpp
15

Below there is no :. You may omit this : as well.

346
compiler-rt/test/asan_abi/lit.cfg.py
14

This file mixes single quotes and double quotes (the file it copied from does so as well). Pick one and be consistent!

rsundahl marked an inline comment as done.May 18 2023, 8:44 AM
rsundahl added inline comments.
compiler-rt/docs/ASanABI.rst
30

How does the 2-space indentation render in the built HTML? It may look good, I ask just in case.

IDK so I played around with it. Global search/replace 2 spaces with 4 does not affect rendering of the block above at all. In the block below there was an effect which was to indent the code blocks one more stop. The reason for this seems to be that the "current indent level" is advanced by 2 in a bulleted list, so below, the code block statement is actually aligned with the bulleted paragraph above it. After the GSR, the code block is indented and rendered further indented. Since bullets advance the "current indent level" by 2, maybe a more natural indent for the source code (.rst) is to use 2 as well. Seems to read a little easier in the source and avoids having to think about all the multiple of 4's after a bullet being "off by 2".

rsundahl marked an inline comment as done.May 18 2023, 8:46 AM
rsundahl updated this revision to Diff 523409.May 18 2023, 9:32 AM

Implement suggestions from latest review.

rsundahl marked 4 inline comments as done.May 18 2023, 9:37 AM

Hello Egenii,

Thank you for your time and consideration of this PR. Since you last commented, @vitalybuka has approved the PR and added @MaskRay and yourself as blocking reviewers. @MaskRay has approved and we are awaiting your approval if you remain positive to it (or let us know if you have any new reservations).

Thank you,
-Roy Sundahl

eugenis accepted this revision.May 24 2023, 2:38 PM
This revision is now accepted and ready to land.May 24 2023, 2:38 PM
MaskRay accepted this revision.May 24 2023, 8:21 PM

LGTM.

compiler-rt/docs/ASanABI.rst
16

Delete .... Sample content implies that this is a code fragment and does not contain everything, so ... is redundant.

23

Quote all compiler driver options with double backsticks.

rsundahl updated this revision to Diff 525644.May 25 2023, 8:44 AM

Apply proper backticks quotes to options. Remove redundant ellipses.

rsundahl marked 2 inline comments as done.May 25 2023, 8:48 AM

Thanks for your time and guidance getting this landed.

This revision was landed with ongoing or failed builds.May 25 2023, 8:58 AM
This revision was automatically updated to reflect the committed changes.