> From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
> Date: Fri, 17 Sep 2021 13:43:19 +0200
>
> On Fri, Sep 17 2021, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >> From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
> >> Date: Fri, 17 Sep 2021 13:23:58 +0200
> >>
> >> On Sat, Sep 04 2021, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
> >> > On Fri, Sep 03 2021, Jeremie Courreges-Anglas <jca@wxcvbn.org> 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 ;).
No comments:
Post a Comment