Upgrade GDB to 8.0.

[jhb]

Summary

This is based on Luca's earlier patch in D11074 but includes some additional
changes:

• Commit b5430a3ced fixes parsing of 32-bit MIPS process cores.
• kgdb has been ported to 8.0 including renaming the new OSABI constant, using gdb_bfd_openr, new return type of ldirname, and solib_add changed.
• The port is now marked as requiring a C++11 library since GDB 8.0 requires C++11.
• patch-armfbsd is updated for the new OSABI constant names (a.out was removed in 8.0) and new filename convention (arm-fbsd-*)
• patch-gdb-amd64-bsd-nat.c (renamed from patch-gdbamd64-bsd-nat.c) is simplified to just store the r_flags value before collecting registers from the register cache rather than a full copy of the entire register set.
• patch-gdb-corelow.c has been removed. It isn't really correct and if arm cores still cause core dumps the error is in arm-fbsd-tdep.c.
• patch-gdb-i386-fbsd-nat.c renamed to account for rename of patched file.
• patch-gdb-x86bsd-nat.c has been removed. The file was renamed, but the stock file also compiled fine for me on i386.

Test Plan

• Built and run-tested package on HEAD amd64, built equivalent git branch on HEAD i386.

[luca.pizzamiglio_gmail.com]

I've tested the new gdb 8 against my test suite and it works really good.
Once PORTREVISION and the python requirements are fixed, the diff is ready to be merged.

devel/gdb/Makefile

6 ↗

(On Diff #30359)

The current PORTREVISION is 2, this part was rejected, but easily fixable

66 ↗

(On Diff #30359)

As stated in the PR 219844, the python dependency can be relaxed in:

PYTHON_USES= python

I've already tested it and it works.

[koobs]

In D11465#237497, @luca.pizzamiglio_gmail.com wrote:

I've tested the new gdb 8 against my test suite and it works really good.
Once PORTREVISION and the python requirements are fixed, the diff is ready to be merged.

These changes (version updates) and 'relax python requirements' should be committed separately (as per FreeBSD Bugzilla Bug 219884 Comment 5)

[jhb]

• Rebase on latest devel/gdb port (including python 3 commit)

[jhb]

Ping? I have two more patchsets from gdb-master to merge into the port ($_siginfo and fs_base/gs_base for amd64) once this is committed.

[luca.pizzamiglio_gmail.com]

We have a heavy build issue on FreeBSD 10.3, on i386 and amd64.
It looks like that clang crashes:

0.      Program arguments: /usr/bin/c++ -cc1 -triple x86_64-unknown-freebsd10.3 -emit-obj -disable-free -disable-llvm-verifier -main-file-name ada-ang.c -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -coverage-file wrkdirs/usr/ports/devel/gdb/work/gdb-8.0/gdb/ada-lang.o -resource-dir /usr/bin/../lib/clang/3.4.1 -D RL_NO_COMPAT -D LIBICONV_PLUG -D IBICONV_PLUG -D LOCALEDIR="/usr/local/share/locale" -D HAVE_CONFIG_H -D TUI=1 -D LIBICONV_PLUG -I . -I . -I ./common -I ./config -I /../include/opcode -I ./../opcodes/.. -I ./../zlib -I ../bfd -I ./../bfd -I ./../include -I ../libdecnumber -I ./../libdecnumber -I ./gnulib/import -I build-gnulib/import -I /usr/local/include -I /usr/local/include/python2.7 -I /usr/local/include/python2.7 -internal-isystem /usr/include/c++/v1 -O2 -Wno-unused-function Wno-unused-variable -Wno-extended-offsetof -Wall -Wpointer-arith -Wno-unused -Wno-switch -Wno-char-subscripts -Wempty-body -Wno-sign-compare -Wno-narrowing -Wformat-nonliteral -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir /wrkdirs/usr/ports/devel/gdb/work/gdb-8.0/gdb -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o ada-lang.o -x c++ ada-lang.c 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 'ada-lang.c'.
4.      Running pass 'SROA' on function '@_ZL25ada_add_global_exceptionsP17re_pattern_bufferPP16VEC_ada_exc_info'
c++: error: unable to execute command: Segmentation fault (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see invocation)

[jhb]

I added dim@ to ask about the clang crash on 10.3. I suspect that this is just a bug in clang and not something we can/should fix in the GDB source code. Perhaps we should just require a newer clang version on stable/10 instead? Looking at Uses/compiler.mk there doesn't seem to be a simple way to do that, though using 'gcc-c++-11-lib' if the OSVERSION is older than 11 might work.

[dim]

In D11465#241105, @jhb wrote:

I added dim@ to ask about the clang crash on 10.3. I suspect that this is just a bug in clang and not something we can/should fix in the GDB source code. Perhaps we should just require a newer clang version on stable/10 instead? Looking at Uses/compiler.mk there doesn't seem to be a simple way to do that, though using 'gcc-c++-11-lib' if the OSVERSION is older than 11 might work.

Is that crash on 10.3-RELEASE, or 10.3-STABLE? There were some fixes after 10.3-RELEASE shipped, this could be one of them. @luca.pizzamiglio_gmail.com, maybe you can upload the .sh and .c file it dropped in /tmp?

[jhb]

Hmm, this just built fine for me on 10.3-RELEASE for amd64 and i386.

[jhb]

Ping. Luca, can you confirm which OS version failed to build for you? 10.3-RELEASE worked here for me on amd64 and i386, but I haven't tried 10-stable.

[luca.pizzamiglio_gmail.com]

Pong,
My poudriere jails are only based on RELEASE, currently 10.3-RELEASE-p20. I've checked the /tmp directory on my poudriere jail and it's empty.
If it works on your jails based on RELEASE, it could be some system limit poudriere is reaching on my laptop. Tomorrow I'll have the opportunity to build it on a bigger server and I'll re-check. An EXP-run maybe can definitely solve it.

[jhb]

Weird, my jails were also releases (via the default https method).

[luca.pizzamiglio_gmail.com]

I ran a build on a different machine, different jail, different poudriere, same error.
The full build log is here.

https://drive.google.com/open?id=0B_S1y98YTyESeERGbllmVXA1a2s

My suggestion is to have a exp-run to verify that on the build cluster it doesn't occur and, if everything is fine, commit it.
Someone on portmgr@ should be able to execute the exp-run.

[luca.pizzamiglio_gmail.com]

devel/gdb/Makefile

17 ↗

(On Diff #30627)

Using compiler:c++14-lang instead of compiler:c++11-lib solves the issue on FreeBSD 10.3, forcing to use a more recent clang version if the installed one is older than 3.5

No extra clang is installed on FreeBSD 11.x

[jhb]

• Require C++14 rather than C++11 as a workaround for clang crashes on 10.3.

[jhb]

devel/gdb/Makefile

17 ↗

(On Diff #30627)

Yep, that is what I was testing locally. I'll add a comment since it is a hack.

[jhb]

Hmm, I didn't submit my comment yesterday. Anyway, the updated version passed an exp-run on 10.3 ok, so are you ok with committing?

[luca.pizzamiglio_gmail.com]

Ok to commit!

[brooks]

LGTM