854810 - Use shared-libraries-*.cc instead of home-grown equivalents

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect)

Description

[Julian Seward [:jseward]]

Bug 779291 inadvertantly duplicated some functionality from
tools/profiler/shared-libraries.cc.  This patch removes that
duplication.

Comment 1

[Julian Seward [:jseward]]

Attachment: Patch

Comment 2

[Benoit Girard (:BenWa)]

Comment on attachment 729438 [details] [diff] [review]
Patch

Review of attachment 729438 [details] [diff] [review]:
-----------------------------------------------------------------

::: tools/profiler/UnwinderThread2.cpp
@@ +1402,5 @@
> +  SharedLibraryInfo info = SharedLibraryInfo::GetInfoForSelf();
> +  for (size_t i = 0; i < info.GetSize(); i++) {
> +    const SharedLibrary& lib = info.GetEntry(i);
> +    // On Linux, this pulls out two mappings with no names: the VDSO
> +    // (understandable but harmless), and the main executable (bad).

Why is the main executable bad? If we can reason about these segments being misleading we can modify SharedLibraryInfo to not include them. This code is only used for symbolication and is shared between the profiler and Telemetry.

Comment 3

[Julian Seward [:jseward]]

(In reply to Benoit Girard (:BenWa) from comment #2)
> Why is the main executable bad?

I meant only that it's bad that shared-libraries.cc produces a mapping
with no name for the main executable, since that means we breakpad
won't be able to read CFI for it, so we won't be able to unwind into
it.  I don't think it matters much -- it's just an annoying
inconsistency.

Comment 4

[Benoit Girard (:BenWa)]

I'll look into modifying the symbolication script to avoid empty name libraries.

Comment 5

[Julian Seward [:jseward]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b5c4adef1523

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b5c4adef1523