This is an archive of the discontinued LLVM Phabricator instance.

[sanitizers] __sanitizer_get_module_and_offset_for_pc interface function
ClosedPublic

Authored by aizatsky on Nov 17 2016, 3:59 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

aizatsky updated this revision to Diff 78426.Nov 17 2016, 3:59 PM
aizatsky retitled this revision from to [sanitizers] __sanitizer_get_module_and_offset_for_pc interface function.
aizatsky updated this object.
aizatsky added a reviewer: kcc.
aizatsky updated this revision to Diff 78427.Nov 17 2016, 4:00 PM

clang-format

kcc added inline comments.Nov 17 2016, 6:20 PM
lib/sanitizer_common/sanitizer_common_libcdep.cc
174 ↗(On Diff #78427)

Hmmmm? Leftover from earlier experiments?

183 ↗(On Diff #78427)

does this need to be null-terminated?

test/sanitizer_common/TestCases/get_module_and_offset_for_pc.cc
25 ↗(On Diff #78427)

please add a loop which will call something like TestCallerPc w/o logging in a long loop,
to ensure that we are not insanely slow.
Ensure that this test really runs slow on the current implementation (with the leftover ListOfModules)

I would also add an extra DSO to the test.
(e.g. like in test/asan/TestCases/Linux/stack-trace-dlclose.cc)

aizatsky marked an inline comment as done.Dec 2 2016, 12:43 PM

ptal

lib/sanitizer_common/sanitizer_common_libcdep.cc
183 ↗(On Diff #78427)

why not? null-terminated strings are easier to work with.

kcc added inline comments.Dec 2 2016, 1:33 PM
lib/sanitizer_common/sanitizer_common_libcdep.cc
183 ↗(On Diff #78427)

probably I badly phrased the question.
Does this code guarantee that the module_name will be null terminated?

lib/tsan/go/buildgo.sh
28 ↗(On Diff #80121)

Ar the changes in this file related to this patch?

aizatsky added inline comments.Dec 2 2016, 1:54 PM
lib/sanitizer_common/sanitizer_common_libcdep.cc
183 ↗(On Diff #78427)

yes. that's how it is stored in LoadedModule.

lib/tsan/go/buildgo.sh
28 ↗(On Diff #80121)

yes. sanitizer_common_libcdep.cc now depends on symbolizer.

kcc added inline comments.Dec 2 2016, 2:13 PM
lib/sanitizer_common/sanitizer_common_libcdep.cc
183 ↗(On Diff #78427)

But what if module_name_len is less than the length of the module string stored in LoadedModule?

aizatsky updated this revision to Diff 80159.Dec 2 2016, 5:38 PM

forcing 0-termination

ptal

lib/sanitizer_common/sanitizer_common_libcdep.cc
183 ↗(On Diff #78427)

Got it. Sorry, a bit slow.

kcc edited edge metadata.Dec 2 2016, 5:47 PM

I am still very much confused on why we have to change build scripts, including things that touch Go and FreeBSD. Something is wrong here (or I can't get it).
Also, __sanitizer_symbolize_pc is defined in sanitizer_stacktrace_libcdep.cc
Wouldn't it be better to implement the new API there as well?

In D26820#612483, @kcc wrote:

I am still very much confused on why we have to change build scripts, including things that touch Go and FreeBSD. Something is wrong here (or I can't get it).

This is what happens without this change on check-all: https://gist.github.com/mikea/53f4dc2c43bab95e97e442be44d5cd72

Also, __sanitizer_symbolize_pc is defined in sanitizer_stacktrace_libcdep.cc
Wouldn't it be better to implement the new API there as well?

I find _stacktrace_libcdep.cc to be unexpected location for symbolization implementation, isn't it?

kcc added a comment.Dec 2 2016, 7:54 PM

Also, __sanitizer_symbolize_pc is defined in sanitizer_stacktrace_libcdep.cc
Wouldn't it be better to implement the new API there as well?

I find _stacktrace_libcdep.cc to be unexpected location for symbolization implementation, isn't it?

stacktrace_libcdep deals with symbolizing stack traces, so an API about symbolizing makes sense there.
And I bet if you move your function there you won't have to change any build files.

In D26820#612518, @kcc wrote:

Also, __sanitizer_symbolize_pc is defined in sanitizer_stacktrace_libcdep.cc
Wouldn't it be better to implement the new API there as well?

I find _stacktrace_libcdep.cc to be unexpected location for symbolization implementation, isn't it?

stacktrace_libcdep deals with symbolizing stack traces, so an API about symbolizing makes sense there.
And I bet if you move your function there you won't have to change any build files.

Moved. It is accidental that it works: go needs a subset of runtime but doesn't actually specify the surface of that runtime. You will get into go runtime by merely putting your code into sanitizer_common_libcdep.cc.

aizatsky updated this revision to Diff 80166.Dec 2 2016, 8:02 PM
aizatsky edited edge metadata.

moved code

kcc accepted this revision.Dec 2 2016, 8:08 PM
kcc edited edge metadata.

LGTM with one nit.

lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc
138 ↗(On Diff #80166)

replace with uptr pc, remove NOLINT, remove the cast below.
Just like in __sanitizer_symbolize_pc.

This revision is now accepted and ready to land.Dec 2 2016, 8:08 PM
aizatsky updated this revision to Diff 80167.Dec 2 2016, 8:17 PM
aizatsky edited edge metadata.

using uptr

lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc
138 ↗(On Diff #80166)

Done except NOLINT.
You need it otherwise clang-tidy complains:

/usr/local/google/home/aizatsky/src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc:136:35: warning: invalid case style for function 'sanitizer_get_module_and_offset_for_pc' [readability-identifier-naming]
SANITIZER_INTERFACE_ATTRIBUTE int
sanitizer_get_module_and_offset_for_pc(

^
SanitizerGetModuleAndOffsetForPc
kcc added a comment.Dec 2 2016, 8:28 PM

Maybe don't use clang-tidy or tune it to accept this naming?
Anyway, up to you.

This revision was automatically updated to reflect the committed changes.