aboutsummaryrefslogtreecommitdiff
path: root/libctf
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2024-10-21 16:41:54 +0100
committerAndrew Burgess <aburgess@redhat.com>2024-12-24 14:15:25 +0000
commit671c82e945f0fb02b58ee6edb47176606adfc3c0 (patch)
tree737dbb1943f506934c3c4eb6fb48aea8a844cfe8 /libctf
parent44a61f1b9f1df069cb1e5de2cd3a1534280b33da (diff)
downloadbinutils-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