public inbox for
 help / color / mirror / Atom feed
From: Gary Benson <>
Subject: [RFC 0/5] New proc_service functionality for Infinity
Date: Thu, 08 Jun 2017 09:15:00 -0000	[thread overview]
Message-ID: <> (raw)

Hi all,

Infinity is a platform-independent system for executables and shared
libraries to expose functionality to debug, monitoring, and analysis
tooling.  Executable and shared library files contain platform-
independent debugging functions that tools like GDB can load and

I've written a prototype libthread_db that uses Infinity functions.
Implementation-specific details such as structure offsets and other
constants are held with the implementation (specifically, in and which means that one can
support any correctly-annotated system, regardless of architecture
or operating system, and without recompilation.  You can, for example,
debug a core file from an aarch64 system running Debian on your
x86_64 laptop that's running Fedora.  You can try this out right now,
there's instructions at:

This series adds proc_service functionality that the Infinity needs.  The series isn't polished, but I'm mailing
it now to get feedback on the two new proc_service functions I'm
proposing in patch 4.  Specifically I'd like feedback on the API,
I'd like to know it's going to be acceptable and make any required
changes now.

The things Infinity needs that the existing proc_service API doesn't
provide are:

 1) The ability to get the contents of a registers in a cross-platform
    environment.  proc_service has ps_lgetregs, but it's not suitable.
    proc_service has no way to determine the inferior's architecture,
    so there's no way to determine the size of the register set you're
    going to get, and no way to determine where in that register set
    the register values you want are.  I've handled this by adding
    ps_get_register, which returns the contents of a single register,
    referenced by its DWARF register number.

 2) The ability to fetch .note.infinity sections from the inferior's
    executable and shared libraries.  With proc_service as it stands,
    you can sort of find the binaries in some cases, but you can't
    find them in all cases GDB supports: if they're in a sysroot, for
    example.  The only way I could think of to reliably solve this in
    all cases GDB supports is to have GDB extract the sections itself
    and supply them to the library via a callback.  It's further
    complicated by the fact that .note.infinity sections contain
    addresses that require relocation.  I've handled this with the
    ps_foreach_infinity_note function.  I'm not 100% happy with how
    complex this part of the API is, but I can't see a simpler way :/



             reply	other threads:[~2017-06-08  9:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  9:15 Gary Benson [this message]
2017-06-08  9:15 ` [RFC 1/5] Add FS_BASE and GS_BASE to DWARF register table on amd64 Gary Benson
2017-06-08  9:15 ` [RFC 3/5] Support ELF Infinity notes Gary Benson
2017-06-08  9:15 ` [RFC 2/5] Add NT_GNU_INFINITY Gary Benson
2017-06-08  9:24 ` [RFC 4/5] Declare Infinity proc_service functions in gdb_proc_service.h Gary Benson
2017-06-08  9:24 ` [RFC 5/5] Implement Infinity proc_service functions in GDB Gary Benson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).