There isn't currently any helper library in the Fuchsia platform to do the ELF parsing for us.  There are several ELFish dependencies already in Chromium:

1. Breakpad has its own "elfutils" library for use under Linux:
https://cs.chromium.org/chromium/src/third_party/breakpad/breakpad/src/common/linux

2. For Android we already pull in a third_party/elfutils:
https://cs.chromium.org/chromium/src/third_party/elfutils
Although that appears to only be used under Android, it's a cross-platform dependency:
https://cs.chromium.org/chromium/src/DEPS?q=elfutils&sq=package:chromium&l=322

Adding a dependency on #1 is not desirable, since that will hamper removal of Breakpad in future.

#2 looks like a more plausible option, but would involve building all of that code into each binary, which seems overkill, and the dependency seems to be there for android_platform tools to build against, in practice.

Option #3 would be to build some minimal custom ELF parser to fetch the buildid, e.g. based on the existing crashlogger-internal ELF parser implementation.

Other options:

1. Use dl_iterate_phdr to find modules, use hand-rolled code to parse PT_NOTE segment from phdrs (I can roll it for you in ~20 lines of C, about the same as what you can crib from numerous places in our code or others).

2. Just let libc log it for you.  These will go out via the loader-service debug RPC, which today eventually gets to the same place as e.g. kernel log messages.  There's no way to route it somewhere else to match where your own logging might be going.  (This will all be better in the future, but not soon enough for you.)
 a. With LD_DEBUG=1 in the environment, ld.so logs all the DSOs at startup (and additional ones at dlopen) in the format the zircon/scripts/symbolize script groks.
 b. Any call to __sanitizer_log_write from <zircon/sanitizer.h> will cause it to log all the DSOs not yet logged, even a 0-length call that doesn't write any other log message.

3. Don't even collect your own stack traces, just have crashlogger do it for you.  If you call crashlogger_request_backtrace() from <zircon/crashlogger.h> then you'll get a crashlogger report like for a crash, but not actually crash.

4. Check with dbort@ about the state of porting Crashpad.

+scottmg, who is working on the Crashpad port for Fuchsia re #4.

If we can really do this in ~20 lines of C then I'd be tempted to do that; we're already enumerating the modules from the link_map (see https://cs.chromium.org/chromium/src/base/debug/stack_trace_fuchsia.cc?type=cs&q=stack_trace_fuchsia&sq=package:chromium&l=137) for our back-trace implementation.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd04777ecd80366d6b55afa2ebf9ffc19c553fd9

commit fd04777ecd80366d6b55afa2ebf9ffc19c553fd9
Author: Wez <wez@chromium.org>
Date: Thu Nov 30 00:53:41 2017

Switch Fuchsia executable runner to use third_party/eu-strip.

Previously we used the host platform's 'strip' command to remove symbols
from binaries while constructing the bootfs, but this was limited to
working with binaries matching the host architecture (i.e. we could not
strip ARM64 binaries on an x64 host).

We addressed this with a Python script capable of working with a wider
variety of architectures. eu-strip can work with both x64 and ARM64
binaries and is already present in Chromium checkouts.

We also switch from stripping binaries manually, at run-time, to doing
so using the strip hook already present in the clang_toolchain build
rules, avoiding the need to re-strip binaries unless they have actually
been re-built since last time.

Bug:  773444 , 772252
Change-Id: I7aab0f3db21a3fcd43433e5de41e2629a15e749c
Reviewed-on: https://chromium-review.googlesource.com/786318
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520354}
[modify] https://crrev.com/fd04777ecd80366d6b55afa2ebf9ffc19c553fd9/build/config/fuchsia/rules.gni
[delete] https://crrev.com/08c0cf8984048bc5c40d01fc679c11b97c17e5a5/build/fuchsia/elfinfo.py
[modify] https://crrev.com/fd04777ecd80366d6b55afa2ebf9ffc19c553fd9/build/fuchsia/runner_common.py
[modify] https://crrev.com/fd04777ecd80366d6b55afa2ebf9ffc19c553fd9/build/toolchain/fuchsia/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e8357b1427fe8b9c0bf5b9a989bd0ebb5d96a039

commit e8357b1427fe8b9c0bf5b9a989bd0ebb5d96a039
Author: Wez <wez@chromium.org>
Date: Wed Dec 06 22:10:44 2017

Quick-fix library lookup by-name for Fuchsia back-trace symbolization.

Bug:  792630 , 772252
Change-Id: I2cd4ea498cbdd614b3469cf92bd4d7b2ee994b39
Reviewed-on: https://chromium-review.googlesource.com/812209
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522223}
[modify] https://crrev.com/e8357b1427fe8b9c0bf5b9a989bd0ebb5d96a039/build/fuchsia/runner_common.py

Blocked on Fuchsia issue DX-209, to provide a symbolizer tool in the SDK.

The NextAction date has arrived: 2018-09-24

DX-209 has progressed such that there is a new crashanalyzer output format which should be in-place in 2-3 weeks, and a corresponding symbolizer tool provided in the SDK.

The NextAction date has arrived: 2018-11-04

The NextAction date has arrived: 2018-12-02