1354546 - Make LUL read CFI from the main executable on x86_64-Linux

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect)

Description

[Julian Seward [:jseward]]

LUL doesn't read CFI from the main executable on x86_64-linux, and possibly
other Linux variants, because SharedLibraryInfo::GetInfoForSelf() doesn't
produce a name for the main executable object, even though it does notice the
mapping.

This causes noticeable unwind breakage because the main executable on Linux
contains various wrapper functions pertaining to memory allocation and locking,
such as

  moz_xmalloc, moz_xcalloc, moz_xrealloc
  mozilla::detail::MutexImpl::lock, mozilla::detail::MutexImpl::unlock

A proper fix is to tidy up shared-libraries-linux.cc and make it able to
identify the main executable properly.  As a short-term fix, we could simply
assume that any nameless object mapped at 0x400000 is the executable.  0x400000
is the "traditional" (x86_64-ELF mandated?) load address for executables on this
platform.

This will fail if the executable is position independent, but at least for
Fedora 25, Ubuntu 16.10 and probably for Debian, that's not the case by default.

This will also fail if (by some amazing chance) some other object with no name
gets mapped to 0x400000, since it will then be mis-identified as the executable.
This doesn't seem very likely, though.

Comment 1

[Julian Seward [:jseward]]

Attachment: A patch implementing said temporary fix.

Comment 2

[Julian Seward [:jseward]]

Attachment: Make LUL read CFI from the main executable on x86_64-Linux

LUL doesn't read CFI from the main executable on x86_64-linux, and possibly
other Linux variants, because SharedLibraryInfo::GetInfoForSelf() doesn't
produce a name for the main executable object, even though it does notice the
mapping.

This causes noticeable unwind breakage because the main executable on Linux
contains various wrapper functions pertaining to memory allocation and locking,
such as

  moz_xmalloc, moz_xcalloc, moz_xrealloc
  mozilla::detail::MutexImpl::lock, mozilla::detail::MutexImpl::unlock

and is generally observable on x86_64-Linux as unwinding failures out of
functions with addresses around 0x40xxxx, since that's the traditional load
address for the main executable.

This patch modifies the Linux implementation of GetInfoForSelf() so as to
harvest the main executable's name from /proc/self/maps.  This is then added
into the information acquired from dl_iterate_phdr.  As a result
GetInfoForSelf() does correctly report the executable name, so LUL reads Dwarf
unwind info from it, and the abovementioned unwinding failures disappear.

Comment 3

[Nicholas Nethercote [inactive]]

Comment on attachment 8856837 [details] [diff] [review]
Make LUL read CFI from the main executable on x86_64-Linux

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

::: tools/profiler/core/shared-libraries-linux.cc
@@ +26,5 @@
>  
>  // There are three different configuration cases:
>  //
>  // (1) GP_OS_linux
> +//       Use dl_iterate_phdr for almost everything and /proc/self/maps to

/proc/self/exe as well?

@@ +143,5 @@
> +  // address of its executable section (exeExeAddr) in the running image.
> +  char exeName[PATH_MAX];
> +  memset(exeName, 0, sizeof(exeName));
> +
> +  ssize_t exeNameLen = readlink("/proc/self/exe", exeName, sizeof(exeName)-1);

Nit: spaces around '-'.

@@ +260,5 @@
> +    SharedLibrary& lib = info.GetMutableEntry(i);
> +    if (lib.GetStart() == exeExeAddr && lib.GetNativeDebugPath() == "") {
> +      nsAutoString exeNameStr;
> +      mozilla::Unused
> +        << NS_WARN_IF(NS_FAILED(NS_CopyNativeToUnicode(

'<<' on preceding line.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fef30348e68c
Make LUL read CFI from the main executable on x86_64-Linux.  r=n.nethercote.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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