> 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 ;).
