Hi Jeremie,
* Jeremie Courreges-Anglas 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
> > - ?
> >
> > Thanks for reading this far, reviews/input welcome.
>
> This time I'm again looking for tests on as many architectures as
> possible.
gdb with your patches compiles fine here on amd64 -current. I have
tested my usual debugging workflow with userland C code (-g3 -ggdb, br,
list, info, print, stepping, etc) and all works as it has worked before.
Cheers and thanks for the update
Matthias
