From: Gary Benson <gbenson@redhat.com>
To: gdb-patches@sourceware.org
Cc: infinity@sourceware.org
Subject: [RFC 0/5] New proc_service functionality for Infinity
Date: Thu, 08 Jun 2017 09:15:00 -0000 [thread overview]
Message-ID: <1496913338-22195-1-git-send-email-gbenson@redhat.com> (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
execute.
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
libpthread.so and ld.so) which means that one libthread_db.so 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:
https://infinitynotes.org/wiki/Third_Eye
This series adds proc_service functionality that the Infinity
libthread_db.so 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 :/
Thanks,
Gary
--
https://infinitynotes.org/
next 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1496913338-22195-1-git-send-email-gbenson@redhat.com \
--to=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=infinity@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).