This is an archive of the discontinued LLVM Phabricator instance.

[dfsan] Add function that prints origin stack trace to buffer
ClosedPublic

Authored by gbalats on May 13 2021, 4:02 PM.

Diff Detail

Event Timeline

gbalats requested review of this revision.May 13 2021, 4:02 PM
gbalats created this revision.
Herald added a subscriber: Restricted Project. · View Herald TranscriptMay 13 2021, 4:02 PM

Please split the sanitizer common change in a separate CL.

Maybe dfsan part can be in a separate patch, but I will not insist.

compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
63

u32

compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp
29–55

I believe we just need to extract this code into a functions and we save some code below.
I do not see benefits of more complicated entities (classes) here over simple functions.

168

We need some tests in sanitizer_stacktrace_test.cpp

compiler-rt/test/dfsan/origin_stack_trace.c
61

second description arg is not tests

Could you please add tests for:

  1. description
  2. dfsan_sprint_origin_trace(..., NULL, 100)
  3. dfsan_sprint_origin_trace(, buff, 0)

Maybe dfsan part can be in a separate patch, but I will not insist.

Please split the sanitizer common change in a separate CL.

please split then

gbalats updated this revision to Diff 345589.May 14 2021, 5:28 PM

Add more tests for both dfsan interface and StackTrace::PrintTo.

gbalats marked 2 inline comments as done.May 14 2021, 5:52 PM

Please split the sanitizer common change in a separate CL.

I will split the sanitizer common parts into a separate patch. However, I find it easier to exercise all tests while making changes for addressing comments, so I will do that in the end.

compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
63

I chose this type in accordance with __sanitizer_symbolize_pc which includes similar parameters. Why is u32 more appropriate here?

compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp
29–55

Out of curiosity, is there a sanitizer developer guide that states such coding preferences more explicitly?

For the given case, I'm not sure how this is possible with simple functions:

  • the classes hold a lot of state; all these fields would have to be passed around as arguments making the functions unwieldy
  • the classes offer encapsulation (e.g., easier to ensure out_buf_ and 'length_' are updated correctly and out_end_ never changes); passing these around to multiple functions I think would make the code much more brittle
  • the common parts that are being abstracted via those classes are the "skeleton" of the algorithm, while only some local operations change (e.g., in one case we call Printf whereas in the other we append to a string buffer); not sure how it's possible to avoid code duplication by using just functions if callbacks (and std::function) isn't an option in the sanitizer world.

For the last part, I ran into this problem when trying to abstract Printf, in particular, which is a variadic function. Without callbacks, a public VPrintf version, and classes how could one write generic code e.g. to abstract the main for-loop (that renders frames) while keeping the actual operation that is performed per frame generic (e.g., a lambda)? Sorry if there's an obvious workaround here but I'm quite new to the sanitizer world.

168

Done.

compiler-rt/test/dfsan/origin_stack_trace.c
61

Done.

vitalybuka added inline comments.May 17 2021, 12:08 PM
compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
63

Actually uptr because this component usually use this type for memory buffer sizes

gbalats updated this revision to Diff 346247.May 18 2021, 12:43 PM
gbalats marked 2 inline comments as done.

Change StackTrace::PrintTo buffer size type to uptr.

gbalats marked an inline comment as done.May 18 2021, 12:43 PM
gbalats added inline comments.
compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
63

Done.

gbalats marked an inline comment as done.May 18 2021, 12:50 PM

Please split the sanitizer common change in a separate CL.

I will split the sanitizer common parts into a separate patch. However, I find it easier to exercise all tests while making changes for addressing comments, so I will do that in the end.

You can do this by keeping both patches in the same git branch and uploading them one by one with "arc diff HEAD^"

gbalats updated this revision to Diff 347094.May 21 2021, 12:03 PM
gbalats marked an inline comment as done.

Split dfsan changes and refactor code to reduce duplication.

gbalats retitled this revision from [dfsan] Add function that prints origin stack trace to buffer. to [dfsan] Add function that prints origin stack trace to buffer.May 21 2021, 12:04 PM
gbalats edited the summary of this revision. (Show Details)
compiler-rt/lib/dfsan/dfsan.cpp
915

This d can be removed.

942

Please add an error message for this case.

944–953

Can you please also extract this part to share with dfsan_print_origin_trace?

gbalats updated this revision to Diff 347121.May 21 2021, 2:07 PM
gbalats marked 2 inline comments as done.

Address comments.

Change behavior on null buffer and zero buffer size.

compiler-rt/lib/dfsan/dfsan.cpp
915

Done.

942

I actually changed this, to be similar to StackTrace::PrintTo. Zero buf size is now legal behavior and returns the correct length (amended test).
As for a null out_buf, changed this to a CHECK-fail since it's always a user error.

944–953

Acknowledged. Variable label is also used below and the return value is different. Also, I don't want to place any print outs inside the PrintOriginTraceToStr helper to minimize its side effects. I thought about having it return an error value or accept an error message string parameter that it can modify, but preferred to keep the code simple and add just some minimum duplication.

This revision is now accepted and ready to land.May 21 2021, 2:11 PM