diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-10-21 16:41:54 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-12-24 14:15:25 +0000 |
commit | 671c82e945f0fb02b58ee6edb47176606adfc3c0 (patch) | |
tree | 737dbb1943f506934c3c4eb6fb48aea8a844cfe8 /libctf | |
parent | 44a61f1b9f1df069cb1e5de2cd3a1534280b33da (diff) | |
download | binutils-671c82e945f0fb02b58ee6edb47176606adfc3c0.zip binutils-671c82e945f0fb02b58ee6edb47176606adfc3c0.tar.gz binutils-671c82e945f0fb02b58ee6edb47176606adfc3c0.tar.bz2 |
gdb/freebsd: port core file context parsing to FreeBSD
This commit implements the gdbarch_core_parse_exec_context method for
FreeBSD.
This is much simpler than for Linux. On FreeBSD, at least the
version (13.x) that I have installer, there are additional entries in
the auxv vector that point directly to the argument and environment
vectors, this makes it trivial to find this information.
If these extra auxv entries are not available on earlier FreeBSD, then
that's fine. The fallback behaviour will be for GDB to act as it
always has up to this point, you'll just not get the extra
functionality.
Other differences compared to Linux are that FreeBSD has
AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is
the full path to the executable. On Linux AT_EXECFN is the command
the user typed, so this can be a relative path.
This difference is handy as on FreeBSD we don't parse the mapped files
from the core file (are they even available?). So having the EXECPATH
means we can use that as the absolute path to the executable.
However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be
the absolute path to the symlink, not to the underlying file. This is
probably a good thing, but it does mean there is one case we test on
Linux that fails on FreeBSD.
On Linux if we create a symlink to an executable, then run the symlink
and generate a corefile. Now delete the symlink and load the core
file. On Linux GDB will still find (and open) the original
executable. This is because we use the mapped file information to
find the absolute path to the executable, and the mapped file
information only stores the real file names, not symlink names.
This is a total edge case, I only added the deleted symlink test
originally because I could see that this would work on Linux. Though
it is neat that Linux finds this, I don't feel too bad that this fails
on FreeBSD.
Other than this, everything seems to work on x86-64 FreeBSD (13.4)
which is all I have setup right now. I don't see why other
architectures wouldn't work too, but I haven't tested them.
Diffstat (limited to 'libctf')
0 files changed, 0 insertions, 0 deletions