Because ratified Zihintpause extension has a version number of 2.0
(not 1.0), we should update the number.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
number of Zihintpause extension.
When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
#0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
(gdb+0x82f3b3)^M
...
which is here:
...
this_cu->dwarf_version = cu->header.version;
...
Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
#1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
#2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
#3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
#1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
sect_offset, bool, bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
#2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
#3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
#4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
(gdb+0x85e68a)^M
#5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
#6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
#7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...
Fix this by setting the field earlier, in read_comp_units_from_section.
The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).
Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section. Instead, verify that the
field already has the value that we're trying to set it to.
Move this logic into into a member function set_version (in analogy to the
already present member function version) to make sure it's used consistenly,
and make the field private in order to enforce access through the member
functions, and rename it to m_dwarf_version.
While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".
Tested on x86_64-linux.
When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.
This is similar to the problem fixed by commit f0bbba7886
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").
In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.
Fix this instead by updating the regexp to allow the message.
Tested on x86_64-linux.
Remove indentation from the text of the manual after the example here:
" Completion will in some cases guide you with a suggestion of what
kind of argument an option expects. For example:
(gdb) print -elements <TAB><TAB>
NUMBER unlimited
Here, the option expects a number (e.g., '100'), not literal
'NUMBER'. Such metasyntactical arguments are always presented in
uppercase."
as this is a continuation of the same paragraph.
Completion results are usually different when the operation is applied
to a word that is or is not followed by a space. In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.
However in the manual we have completion examples given using a space
that actually prevents the example from working. E.g.:
(gdb) info bre <TAB>
(nothing) and:
(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)
as it now goes on to propose the entire symbol table, while:
(gdb) info bre<TAB>
(gdb) info breakpoints
does the right thing, but is not what is shown in the manual.
In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.
Remove extraneous spaces then from completion examples as appropriate.
Fix a completion consistency issue with `set' commands accepting integer
values and the special `unlimited' keyword:
(gdb) complete print -elements
print -elements NUMBER
print -elements unlimited
(gdb)
vs:
(gdb) complete set print elements
set print elements unlimited
(gdb)
(there is a space entered at the end of both commands, not shown here)
which also means if you strike <Tab> with `set print elements ' input,
it will, annoyingly, complete to `set print elements unlimited' right
away rather than showing a choice between `NUMBER' and `unlimited'.
Add `NUMBER' then as an available completion for such `set' commands:
(gdb) complete set print elements
set print elements NUMBER
set print elements unlimited
(gdb)
Adjust the testsuite accordingly. Also document the feature in the
Completion section of the manual in addition to the Command Options
section already there.
When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.
* dwarf.c (dwarf_select_sections_by_name): If the entry's value is
zero then clear the corresponding variable.
(dwarf_select_sections_by_letters): Likewise.
* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
debuginfod tests to fail.
With gdb build with gcc-12 and -fsanitize=thread, and test-case
gdb.base/gdb-sigterm.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=9722)^M
Write of size 4 at 0x00000325bc68 by thread T1:^M
#0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
...
Previous read of size 4 at 0x00000325bc68 by main thread:^M
[failed to restore the stack]^M
^M
Location is global 'sync_quit_force_run' of size 4 at \
0x00000325bc68 (gdb+0x325bc68)^M
...
SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
handle_sigterm(int)^M
...
and 3 more data races involving handle_sigterm and locations:
- active_ext_lang
- quit_flag
- heap block of size 40
(XNEW (async_signal_handler) in create_async_signal_handler)
This was reported in PR29297.
The testcase executes a "kill -TERM $gdb_pid", which generates a
process-directed signal.
A process-directed signal can be delivered to any thread, and what we see
here is the fallout of the signal being delivered to a worker thread rather
than the main thread.
Fix this by blocking SIGTERM in the worker threads.
[ I have not been able to reproduce this after it occurred for the first time,
so unfortunately I cannot confirm that the patch fixes the problem. ]
Tested on x86_64-linux, with and without -fsanitize=thread.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297
In passing I noticed that the column headings for the table of MI
compatibility and breaking changes, were overlapping, at least when
the PDF is generated on my machine.
I propose giving slightly more space to the two version number
columns, this prevents the headers overlapping for me.
Simon reported that the recent change to make GDB and GDBserver avoid
reading shell registers caused a GDBserver regression, caught with
ASan while running gdb.server/non-existing-program.exp:
$ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
=================================================================
==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
WRITE of size 1 at 0x60f0000000e9 thread T0
#0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
#1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
#2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
#3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
#4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
#5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)
0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
freed by thread T0 here:
#0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
#2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
#3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
#4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
#5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
#6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
#7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
#8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
#9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
#10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
previously allocated by thread T0 here:
#0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
#2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
#3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
#4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
#5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
#6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
Above we see that in the non-existing-program case, the process gets
deleted before the starting_up flag gets restored to false.
This happens because startup_inferior calls target_mourn_inferior
before throwing an error, and in GDBserver, unlike in GDB, mourning
deletes the process.
Fix this by not using a scoped_restore to manage the starting_up flag,
since we should only clear it when startup_inferior doesn't throw.
Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c
Match the whole error message expected to be given rather than omitting
the part about the "unlimited" keyword. There's no point in omitting
the missing part first, and second with an upcoming change the part in
parentheses will no longer be a fixed string, so doing a full match will
ensure the algorithm correctly builds the message expected here. Also
avoid any wildcard matches.
With errors given for bad commands such as `set annotate' or `set width'
we produce an extraneous full stop within parentheses:
(gdb) set annotate
Argument required (integer to set it to.).
(gdb) set width
Argument required (integer to set it to, or "unlimited".).
(gdb)
This is grammatically incorrect, so remove the full stop and adjust the
testsuite accordingly.
Extend the description of the MI command --data-disassemble.
Specifically, expand the description of the 'opcodes' field to explain
how the bytes are formatted.
The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure. If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
The function aarch64_print_operand (aarch64-opc.c) is responsible for
converting an instruction operand into the textual representation of
that operand.
In some cases, a comment is included in the operand representation,
though this (currently) only happens for the last operand of the
instruction.
In a future commit I would like to enable the new libopcodes styling
for AArch64, this will allow objdump and GDB[1] to syntax highlight
the disassembler output, however, having operands and comments
combined in a single string like this makes such styling harder.
In this commit, I propose to extend aarch64_print_operand to take a
second buffer. Any comments for the instruction are written into this
extra buffer. The two callers of aarch64_print_operand are then
updated to pass an extra buffer, and print any resulting comment.
In this commit no styling is added, that will come later. However, I
have adjusted the output slightly. Before this commit some comments
would be separated from the instruction operands with a tab character,
while in other cases the comment was separated with two single spaces.
After this commit I use a single tab character in all cases. This
means a few test cases needed updated. If people would prefer me to
move everyone to use the two spaces, then just let me know. Or maybe
there was a good reason why we used a mix of styles, I could probably
figure out a way to maintain the old output exactly if that is
critical.
Other than that, there should be no user visible changes after this
commit.
[1] GDB patches have not been merged yet, but have been posted to the
GDB mailing list:
https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html
When running the gdb.base/break-idempotent.exp test on ppc, I was
seeing some test failures (or rather errors), that looked like this:
(gdb) watch local
Hardware watchpoint 2: local
has_hw_wp_support: Hardware watchpoint detected
ERROR: no fileid for gcc2-power8
ERROR: Couldn't send delete breakpoints to GDB.
ERROR OCCURED: can't read "gdb_spawn_id": no such variable
while executing
"expect {
-i 1000 -timeout 100
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_erro..."
("uplevel" body line 1)
invoked from within
What happens is that in break-idempotent.exp we basically do this:
if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
continue
}
# ....
if {![skip_hw_watchpoint_tests]} {
test_break $always_inserted "watch"
}
The problem with this is that skip_hw_watchpoint_tests, includes this:
if { [istarget "i?86-*-*"]
|| [istarget "x86_64-*-*"]
|| [istarget "ia64-*-*"]
|| [istarget "arm*-*-*"]
|| [istarget "aarch64*-*-*"]
|| ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
|| [istarget "s390*-*-*"] } {
return 0
}
For powerpc only we call has_hw_wp_support. This is a caching proc
that runs a test within GDB to detect if we have hardware watchpoint
support or not.
Unfortunately, to run this test we restart GDB, and when the test has
completed, we exit GDB. This means that in break-idempotent.exp, when
we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
will unexpectedly be exited. When we later call delete_breakpoints we
see the errors I reported above.
The fix is to call skip_hw_watchpoint_tests early, before we start GDB
as part of the break-idempotent.exp script, and store the result in a
variable, we can then check this variable in the script as needed.
After this change break-idempotent.exp runs fine on powerpc.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
gprofng/ChangeLog
2022-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29131
* gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true.
* src/Makefile.am: Likewise.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.
commit d0e0f9c87a results "ERROR: i586-linux-cc does not exist" if
cross-building an i586-linux target without a target compiler
installed.
* testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New.
Use it after first testing check_compiler_available.
For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc. This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc. However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.
In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.
However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).
So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.
We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early. While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.
Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
When building gdb with system gcc 7.5.0, I run into:
...
gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
[-Werror=return-type]
...
This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
-Wreturn-type warning", which has been fixed in gcc-8.
Work around this by moving the default return outside the switch.
Tested on x86_64-linux.
Even if MS docs say that CP_UTF8 should always be used on newer
applications, forcing it might produce undefined filename if the
encoding isn't UTF-8.
MinGW seems to call ___lc_codepage_func() in order to retrieve the
current thread codepage.
bfd/ChangeLog:
* bfdio.c (_bfd_real_fopen): Retrieve codepage with
___lc_codepage_func() on MinGW.
This patch ensures that the gcc binary called by windres is quoted if
needed. Otherwise, errors can occur if the gcc is under a folder having
a name containing a space (eg "Program Files").
binutils/
* resrc.c (DEFAULT_PREPROCESSOR): Split into...
(DEFAULT_PREPROCESSOR_CMD): that...
(DEFAULT_PREPROCESSOR_ARGS): and that.
(look_for_default): Add quotes around the command if needed.
(read_rc_file): Adapt to new defines.
PR 29267
* dwarf.c (display_debug_rnglists): New function, broken out of..
(display_debug_ranges): ... here.
(read_and_display_attr_value): Correct calculation of index
displayed for DW_FORM_loclistx and DW_FORM_rnglistx.
* testsuite/binutils-all/x86-64/pr26808.dump: Update expected
output.
When the compiler doesn't properly arrange for foo's alignment, there's
no point even trying these tests. Report the situation as a single
"unsupported" test.
plt_branch stubs are similar to plt_call stubs in that they branch
via bctr. Align them too.
bfd/
* elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for
plt_call stubs.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes.
* testsuite/ld-powerpc/notoc.d: Likewise.
* testsuite/ld-powerpc/notoc.wf: Likewise.
* testsuite/ld-powerpc/notoc3.d: Likewise.
* testsuite/ld-powerpc/pr23937.d: Likewise.
* elf64-ppc.c (plt_stub_pad): Simplify parameters and untangle
from plt_stub_size.
(ppc_size_one_stub): Call plt_stub_size before plt_stub_pad to
provide size. Recalculate size if it might change.
It made sense before I started using separate fields for main type and
sub type to add a difference in main type to the type (thus keeping
sub type unchanged). Not so much now.
* elf64-ppc.c (ppc_merge_stub): Simplify stub type change.
(ppc_size_one_stub): Likewise.
In the existing CSKY architecture, there are at most 32 floating
and 16 vector registers. Float registers's count can be configured
as 16 or 32. In the future, the vector registers's count may be
extended to 32.
The bit width of floating-point register is 64bits, and the bit
width of vector register is 128bit.
Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower
64 bits of the corresponding VRx.
Here, we will split each floating-point and vector register to
32bits wide, add the corresponding pseudo registers, and finally
use them for the dwarf registers.
There are 128 pseudo registers in total, s0~s127, including:
1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on.
Every two separated pseudo registers correspond to a float register.
2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1,
and so on. Every four pseudo registers corresponds to a vector register.
Therefore, in s64~s127, there are general registers that are not actually
used. This part is to prepare for the expansion of vector registers to 32
Therefore, in s64~s127, half of the registers are actually unused. This
part is to prepare for the expansion of the vector register to 32.
To support feature gate like Smstateen && H, this commit adds certain
CSR feature gate handling. It also changes how RV32-only CSRs are
handled for cleanliness.
gas/ChangeLog:
* config/tc-riscv.c (riscv_csr_address): Add CSR feature gate
handling for H. Change handling on RV32.
Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen.
gdb.base/macscp.exp was referencing bug number 555, and the bug 7660
mentions that it used to be 555 on the Gnats system and seems to relate
to the issue at hand.
gdb.base/annota1.exp was referencing bug number 1270, and bug 8375
mentions being number 1270 on Gnats, and mentions annota1 specifically,
so it seemed pretty obvious.
When building gdb with --enable-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
`.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
`inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...
This is a regression since commit a08bdb159b ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").
The problem is that a single case statement in configure is shared to handle
special requirements for both the host libiberty and host zlib, which has the
effect that only one is handled.
Fix this by handling libiberty and zlib each in its own case statement.
Build on x86_64-linux, with and without --enable-shared.
ChangeLog:
2022-06-27 Tom de Vries <tdevries@suse.de>
* configure.ac: Set extra_host_libiberty_configure_flags and
extra_host_zlib_configure_flags in separate case statements.
* configure: Regenerate.
Currently, if GDBserver hits some internal assertion, it exits with
error status, instead of aborting. This makes it harder to debug
GDBserver, as you can't just debug a core file if GDBserver fails an
assertion. I've had to hack the code to make GDBserver abort to debug
something several times before.
I believe the reason it exits instead of aborting, is to prevent
potentially littering the filesystem of smaller embedded targets with
core files. I think I recall Daniel Jacobowitz once saying that many
years ago, but I can't be sure. Anyhow, that seems reasonable to me.
Since we nowadays have a distinction between development and release
modes, I propose to make GDBserver abort on internal error if in
development mode, while keeping the status quo when in release mode.
Thus, after this patch, in development mode, you get:
$ ../gdbserver/gdbserver
../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
captured_main: Assertion `0' failed.
Aborted (core dumped)
$
while in release mode, you'll continue to get:
$ ../gdbserver/gdbserver
../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
captured_main: Assertion `0' failed.
$ echo $?
1
I do not think that this requires a separate configure switch.
A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends
up with:
=== gdb Summary ===
# of unexpected core files 29
...
for me, of which 8 are GDBserver core dumps, 7 more than without this
patch.
Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
