> Date: Fri, 17 Sep 2021 13:58:46 +0200 (CEST) > From: Mark Kettenis <[email protected]> > > > From: Jeremie Courreges-Anglas <[email protected]> > > Date: Fri, 17 Sep 2021 13:43:19 +0200 > > > > On Fri, Sep 17 2021, Mark Kettenis <[email protected]> wrote: > > >> From: Jeremie Courreges-Anglas <[email protected]> > > >> Date: Fri, 17 Sep 2021 13:23:58 +0200 > > >> > > >> On Sat, Sep 04 2021, Jeremie Courreges-Anglas <[email protected]> wrote: > > >> > On Fri, Sep 03 2021, Jeremie Courreges-Anglas <[email protected]> wrote: > > >> >> So here's the result of the torture I've been doing to my self during > > >> >> this hackathon. gdb-10.x inferior target support is broken for > > >> >> reasons > > >> >> I still ignore and I've been told that moving to 9.x was already nice > > >> >> enough. :) > > >> >> > > >> >> Regarding the changes below: > > >> >> - DEBUG_PACKAGES, reminded by sthen@ > > >> >> - disable mpfr, linking against libgmp.a breaks on powerpc with > > >> >> relocation errors > > >> >> - xxhash support added, just because it took me less time to just add > > >> >> the dep. I didn't actually check for all possible new hidden deps > > >> > > > >> > To keep things simple I just force-disabled everything that seemed > > >> > relevant. > > >> > > > >> >> - CFLAGS tweak maybe not needed any more? If this actually requires > > >> >> C11 or C++11 support, COMPILER should be changed > > >> > > > >> > The port now requires C++11 support and thus base-clang or ports-gcc > > >> > (tested on sparc64 with COMPILER=base-gcc). Both base-clang and > > >> > ports-gcc default to C17 so no need to specify -std=gnu11. > > >> > > > >> > So along with m88k this also kills egdb support on sh (no idea whether > > >> > it actually built/worked there, I only know that one file was patched). > > >> > I don't consider this as a showstopper. If people care about egdb on > > >> > those architectures it should be possible to add a devel/gdb-7 port. > > >> > > > >> >> - upstream moved file named <arch><system> to <arch>-<system> so I > > >> >> moved > > >> >> our files too, sorry for the churn. > > >> >> - I also had to adapt our aarch64 and powerpc64 support patches to the > > >> >> API changes that happened upstream > > >> >> - i386 needed special love, some changes that happened in there > > >> >> haven't > > >> >> been compile tested > > >> >> - the ptid_get_pid->get_ptrace_pid issue has been solved upstream, so > > >> >> a bunch of patches get removed > > >> >> - some of the configure.nat dedup changes aren't strictly needed but > > >> >> they just seem better in the long term. For example some of our > > >> >> architectures didn't use bsd-kvm.c/libkvm. > > >> >> - OpenBSD/riscv64 support files shamelessly copied from the FreeBSD > > >> >> support (thanks!). Besides mechanical renaming, I think it's the > > >> >> only > > >> >> relevant change I made there. riscv64 support means we can read > > >> >> coredumps and print backtraces. We can't do inferior process > > >> >> debugging yet because we just don't support PT_STEP (this may also > > >> >> be > > >> >> a problem on other architectures). We also need a kernel diff that > > >> >> I haven't sent yet. > > >> >> - m88k support has been removed, sorry aoyama@ :-/ > > >> >> - the python patch isn't needed anymore > > >> > > > >> > - added in the diff below: two hunks to keep building on OpenBSD/armv7, > > >> > I had lost those bits initially present in Pascal's update to 8.2.1. > > >> > > > >> >> Thanks to all the folks who helped me test a previous diff on various > > >> >> architectures! Even if there are still open questions (and I may have > > >> >> forgotten some so reviews would be welcome), I hope we can commit this > > >> >> update before tagging OpenBSD 7.0. Therefore I'll need another round > > >> >> of > > >> >> tests! > > >> >> > > >> >> Things to test with -current devel/gdb *and* after applying the diff > > >> >> below: > > >> >> - egdb -ex run <dynamic program> # for example du > > >> >> - egdb -ex run <static program> # for example ls > > >> > > > >> > More complete/automated tests: > > >> > - egdb -ex 'b main' -ex run -ex bt -ex continue -ex q > > >> > /usr/src/usr.bin/du/obj/du > > >> > - egdb -ex 'b main' -ex run -ex bt -ex continue -ex q > > >> > /usr/src/bin/ls/obj/ls > > >> > > > >> >> - reading a coredump and printing a backtrace > > >> >> - ? > > >> > > >> Updated diff after some tweaks and successful tests by jj@ on octeon. > > >> > > >> arch-specific test reports so far: > > >> - ok: amd64, riscv64, sparc64, i386, powerpc, powerpc64, octeon > > >> - not ok: arm64 (don't know how to run) > > >> - unknown: alpha, armv7, hppa, loongson > > >> - not applicable: sh, m88k > > >> > > >> Apart from the "unknown" architectures above, new tests on arm64 would > > >> be sweet. The support for native inferior target should be hooked up > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> now - but it may fail to build. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > >> > > >> (gdb-9.2-8.diff) > > > > > > Not sure what I'm doing wrong, but for me arm64 doesn't even build... > > > > I would suspect errors compiling aarch64-obsd-nat.c, right? If you send > > me the error log I might be able to fix them. > > Yes. I can fix it myself, such that you can concentrate on the other > missing bits. It's just that your message suggests it builds but > doesn't run properly. So I was trying to avoid work you have already > done ;).
The files below are what I came up with to make arm64 build. Some light testing suggests that it actually works! I attached the files I changed (aarch64-obsd-tdep.h is new). That should allow you to update the diff. The files can also be found in my home dir on cvs.
aarch64-obsd-nat.c
Description: Binary data
aarch64-obsd-tdep.h
Description: Binary data
aarch64-obsd-tdep.c
Description: Binary data
