This exposes the internal error Don mentioned in PR19496:
(1) internal error -- gdb/target.c:2713: internal-error: Can't determine the current address space of thread
More analysis here:
https://sourceware.org/ml/gdb-patches/2016-01/msg00685.html
The (now kfailed) internal error looks like:
continue &
Continuing.
(gdb) PASS: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: continue &
[New Thread 2846.2847]
(...)
[New Thread 2867.2867]
/home/pedro/gdb/mygit/src/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 2846.2846
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) KFAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error) (PRMS: remote/19496)
Resyncing due to internal error.
gdb/testsuite/ChangeLog:
2016-02-01 Pedro Alves <palves@redhat.com>
PR remote/19496
* gdb.threads/forking-threads-plus-breakpoint.exp
(displaced_stepping_supported): New global.
(probe_displaced_stepping_support): New procedure.
(do_test): Add 'displaced' parameter, and use it.
(top level): Check for displaced stepping support. Add displaced
stepping on/off testing axis.
The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF
generated by gfortran.
In the test a pointer variable 'pvla2' is created:
real, pointer :: pvla2 (:, :)
Initially this variable will be unassociated, so something like this:
l = associated(pvla2)
should return false.
In the test gdb stops at a point _before_ pvla2 is associated with
anything, and we then try to print pvla2, the expectation is that gdb
should reply <not associated>.
The problem is that the data the DWARF directs gdb to read (to identify
if the variable is associated or not) is not initialised until the first
time pvla2 is accessed.
As a result gdb ends up reading uninitialised memory, sometimes this
uninitialised memory indicates the variable is associated (when it's
not). This first mistake can lead to a cascade of errors, reading
uninitialised memory, with the result that gdb builds an invalid type to
associate with the variable pvla2.
In some cases, this invalid type can be very large, which when we try to
print pvla2 causes gdb to allocate a large amount of memory.
A recent commit added a new gdb variable 'max-value-size', which
prevents gdb from allocating values of extreme size. As a result
directly trying to print pvla2 will now now error rather than allocate a
large amount of memory.
However, some of the later tests create a varobj for pvla2, and then
ask for the children of that varobj to be displayed. In the case where
an invalid type has been computed for pvla2 then the number of children
can be wrong, and very big, in which case trying to display all of these
children can cause gdb to consume an excessive amount of memory.
This commit first detects if printing pvla2 triggers the max-value-size
error, if it does then we avoid all the follow on tests relating to the
unassociated pvla2, which avoids the second error printing the varobj
children.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated
pointer. Don't perform further tests on the unassociated pointer
if the first test fails.
For languages with dynamic types, an incorrect program, or uninitialised
variables within a program, could result in an incorrect, overly large
type being associated with a value. Currently, attempting to print such
a variable will result in gdb trying to allocate an overly large buffer.
If this large memory allocation fails then the result can be gdb either
terminating, or (due to memory contention) becoming unresponsive for the
user.
A new user visible variable in gdb helps guard against such problems,
two new commands are available:
set max-value-size
show max-value-size
The 'max-value-size' is the maximum size of memory in bytes that gdb
will allocate for the contents of a value. Any attempt to allocate a
value with a size greater than this will result in an error. The
initial default for this limit is set at 64k, this is based on a similar
limit that exists within the ada specific code.
It is possible for the user to set max-value-size to unlimited, in which
case the old behaviour is restored.
gdb/ChangeLog:
* value.c (max_value_size): New variable.
(MIN_VALUE_FOR_MAX_VALUE_SIZE): New define.
(show_max_value_size): New function.
(check_type_length_before_alloc): New function.
(allocate_value_contents): Call check_type_length_before_alloc.
(set_value_enclosing_type): Likewise.
(_initialize_values): Add set/show handler for max-value-size.
* NEWS: Mention new set/show command.
gdb/doc/ChangeLog:
* gdb.texinfo (Value Sizes): New section.
(Data): Add the 'Value Sizes' node to the menu.
gdb/testsuite/ChangeLog:
* gdb.base/max-value-size.c: New file.
* gdb.base/max-value-size.exp: New file.
* gdb.base/huge.exp: Disable max-value-size for this test.
Changing "pushq $1" in the following to "pushq $too_big" results in an
abort. BFD shouldn't abort on (deliberately) bad user input.
400480: ff 25 9a 0b 20 00 jmpq *0x200b9a(%rip)
400486: 68 01 00 00 00 pushq $0x1
40048b: e9 d0 ff ff ff jmpq 400460 <_init+0x20>
* elf64-x86-64.c (elf_x86_64_get_plt_sym_val): Don't abort on
an out of range reloc_index.
* elf32-i386.c (elf_i386_get_plt_sym_val): Likewise.
A few typos. The comment about varobj_create has been misplaced since
the dawn of time.
gdb/ChangeLog:
* varobj.h (struct varobj): Fix typos in comments.
(struct lang_varobj_ops): Likewise.
* varobj.c (VAROBJ_TABLE_SIZE): Likewise.
(varobj_create): Move misplaced comment.
../../bfd/elf64-s390.c: In function 'elf_s390_reloc_name_lookup':
../../bfd/elf64-s390.c:340:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
if (strcasecmp (elf64_s390_vtinherit_howto.name, r_name) == 0)
^~
../../bfd/elf64-s390.c:333:3: note: ...this 'for' clause, but it is not
for (i = 0;
^~~
bfd/
* elf64-s390.c (elf_s390_reloc_name_lookup): Fix indentation.
There is no need to check relocation IFUNC symbol if there are no
dynamic symbols.
bfd/
PR ld/19539
* elf32-i386.c (elf_i386_reloc_type_class): Check relocation
against STT_GNU_IFUNC symbol only with dynamic symbols.
* elf64-x86-64.c (elf_x86_64_reloc_type_class): Likewise.
ld/
PR ld/19539
* testsuite/ld-elf/pr19539.d: New file.
* testsuite/ld-elf/pr19539.s: Likewise.
* testsuite/ld-elf/pr19539.t: Likewise.
Two small changes so everything builds with latest GCC and its
-Wmisleading-indentation.
In the aarch64-tdep.c case, the two misindented lines should actually be
part of the for loop. It looks like the indentation is all done using
spaces in that file though... I fixed it (changed for tabs + spaces) for
the lines I touched.
In the xcoffread.c case, we can simply remove the braces and fix the
indentation.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_record_asimd_load_store): Add braces
to for include additional lines.
* xcoffread.c (scan_xcoff_symtab): Remove unnecessary braces.
We should set BFD_DECOMPRESS to decompress debug sections when reading in
DWARF debug sections.
bfd/
PR binutils/19523
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Set BFD_DECOMPRESS to
decompress debug sections.
binutils/
PR binutils/19523
* Makefile.am (check-DEJAGNU): Pass CC and CC_FOR_BUILD to
runtest.
* Makefile.in: Regenerated.
* testsuite/binutils-all/compress.exp (test_gnu_debuglink): New
proc.
Run test_gnu_debuglink for native ELF build.
libiberty/ChangeLog:
* d-demangle.c (dlang_call_convention): Handle extern Objective-C
function calling convention.
(dlang_call_convention_p): Likewise.
(dlang_type): Likewise.
* testsuite/d-demangle-expected: Add coverage tests.
* d-demangle.c (dlang_function_args): Append ',' for variadic functions
only if parameters were seen before the elipsis symbol.
* testsuite/d-demangle-expected: Add coverage test for parameter-less
variadic functions.
* d-demangle.c (dlang_type): Handle function types only in the context
of seeing a pointer type symbol.
* testsuite/d-demangle-expected: Update function pointer tests.
rawmemchr is a dependency of strchrnul, so it should be explicitly
listed.
gdb/ChangeLog:
* gnulib/import/Makefile.am: Regenerate.
* gnulib/import/Makefile.in: Regenerate.
* gnulib/import/m4/gnulib-cache.m4: Regenerate.
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add rawmemchr.
For a forthcoming patch, I need a "skip_to_colon" function. I noticed
there are two skip_to_semicolon (one in gdb and one in gdbserver). I
thought we could put it in common/, and generalize it for any character.
It turns out that the strchrnul function does exactly that. I imported
the corresponding module from gnulib, for those systems that do not have
it.
There are probably more places where this function can be used instead
of doing the work by hand (I am looking at
remote-utils.c::look_up_one_symbol).
gdb/ChangeLog:
* remote.c (skip_to_semicolon): Remove.
(remote_parse_stop_reply): Use strchrnul instead of
skip_to_semicolon.
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
strchrnul.
* gnulib/aclocal.m4: Regenerate.
* gnulib/config.in: Regenerate.
* gnulib/configure: Regenerate.
* gnulib/import/Makefile.am: Regenerate.
* gnulib/import/Makefile.in: Regenerate.
* gnulib/import/m4/gnulib-cache.m4: Regenerate.
* gnulib/import/m4/gnulib-comp.m4: Regenerate.
* gnulib/import/m4/rawmemchr.m4: New file.
* gnulib/import/m4/strchrnul.m4: New file.
* gnulib/import/rawmemchr.c: New file.
* gnulib/import/rawmemchr.valgrind: New file.
* gnulib/import/strchrnul.c: New file.
* gnulib/import/strchrnul.valgrind: New file.
gdb/gdbserver/ChangeLog:
* server.c (skip_to_semicolon): Remove.
(process_point_options): Use strchrnul instead of
skip_to_semicolon.
In vla.f90, this single line of source is compiled to many instructions,
vla2(:, :, :) = 1311 ! vla2-allocated
it is quite slow (about several minutes in my testing) to step over this
source line without range stepping. This patch is to increase the timeout
value by 15 times, which is a magic number to make sure timeout disappears
in my testing with a slow arm-linux board.
gdb/testsuite:
2016-01-28 Yao Qi <yao.qi@linaro.org>
* gdb.fortran/vla-value.exp: Wrap test with with_timeout_factor.
I see GDB crashes in dprintf.exp on aarch64-linux testing,
(gdb) PASS: gdb.base/dprintf.exp: agent: break 29
set dprintf-style agent^M
(gdb) PASS: gdb.base/dprintf.exp: agent: set dprintf style to agent
continue^M
Continuing.
ASAN:SIGSEGV
=================================================================
==22475==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000494820 sp 0x7fff389b83a0 bp 0x62d000082417 T0)
#0 0x49481f in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9190^M
#1 0x49e576 in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9174^M
#2 0x49e576 in remote_insert_breakpoint /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9240^M
#3 0x5278b7 in insert_bp_location /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:2734^M
#4 0x52ac09 in insert_breakpoint_locations /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:3159^M
#5 0x52ac09 in update_global_location_list /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:12686
the root cause of this problem in this case is about linespec and
symtab which produces additional incorrect location and a NULL is added to
bp_tgt->tcommands. I posted a patch
https://sourceware.org/ml/gdb-patches/2015-12/msg00321.html to fix it
in linespec (the fix causes regression), but GDB still shouldn't add
NULL into bp_tgt->tcommands. The logic of build_target_command_list
looks odd to me. If we get something wrong in parse_cmd_to_aexpr (it
returns NULL), we shouldn't continue, instead we should set flag
null_command_or_parse_error. This is what this patch does. In the
meantime, we find build_target_condition_list has the same problem, so
fix it too.
gdb:
2016-01-28 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (build_target_command_list): Don't call continue
if aexpr is NULL.
(build_target_condition_list): Likewise.
Nowadays, get_next_pcs in linux_target_ops has two parameters PC
and REGCACHE. Parameter PC looks redundant because it can be go
from REGCACHE. The patch is to remove PC from the arguments for
various functions.
gdb:
2016-01-26 Yao Qi <yao.qi@linaro.org>
* arch/arm-get-next-pcs.c (thumb_deal_with_atomic_sequence_raw):
Remove argument pc. Get pc by regcache_read_pc. Callers updated.
(arm_deal_with_atomic_sequence_raw): Likewise.
(thumb_get_next_pcs_raw): Likewise.
(arm_get_next_pcs_raw): Likewise.
(arm_get_next_pcs): Remove argument pc. Callers updated.
* arch/arm-get-next-pcs.h (arm_get_next_pcs): Update declaration.
gdb/gdbserver:
2016-01-26 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_gdbserver_get_next_pcs): Remove argument pc.
* linux-low.c (install_software_single_step_breakpoints): Don't
call regcache_read_pc.
* linux-low.h (struct linux_target_ops) <get_next_pcs>: Remove
argument pc.
In install_software_single_step_breakpoints, we've got the regcache
of current_thread, so we don't have to bother get_pc to get pc,
instead we can get pc from regcache directly. Note that the callers
of install_software_single_step_breakpoints have already switched
current_thread to LWP.
Since the pc is got from regcache_read_pc, in the next patch, we can
get pc inside the implementation of *the_low_target.get_next_pcs and
stop passing pc to *the_low_target.get_next_pcs.
gdb/gdbserver:
2016-01-26 Yao Qi <yao.qi@linaro.org>
* linux-low.c (install_software_single_step_breakpoints): Call
regcache_read_pc instead of get_pc.
Nowadays, GDBserver disables async io (by ignoring SIGIO) when process
a serial event, and enables async io (by installing signal handler) when
resume the inferior and wait. GDBserver may miss SIGIO (by interrupt)
and doesn't process SIGIO in time, which is shown by
gdb.base/interrupt-noterm.exp. In the test, GDB sends "continue &" and
then "interrupt". if '\003' arrives at a period between GDBserver
receives vCont;c and enables async io, SIGIO is ignored because signal
handler isn't installed. GDBserver waits for the inferior and can not
notice '\003' until it returns from wait.
This patch changes the code to install SIGIO handler early, but block
and unblock SIGIO as needed. In this way, we don't remove SIGIO
handler, so SIGIO can't be ignored. However, GDBserver needs to
remove the signal handler when connection is closed.
gdb/gdbserver:
2016-01-26 Yao Qi <yao.qi@linaro.org>
* remote-utils.c (remote_close) [!USE_WIN32API]: Ignore SIGIO.
(unblock_async_io): Rename to ...
(block_unblock_async_io): ... it. New function.
(enable_async_io): Don't install SIGIO handler. Unblock it
instead.
(disable_async_io): Don't ignore SIGIO. Block it instead.
(initialize_async_io): Install SIGIO handler. Don't call
unblock_async_io.
GDBserver may read some packet together with '\003' in one go. We've
already checked '\003' first when reading packet by my patch,
Check input interrupt first when reading packet
https://sourceware.org/ml/gdb-patches/2016-01/msg00057.html
but if we don't check '\003' *after* each packet, the interrupt will
be processed next time GDBserver reads from the buffer, so that the
interrupt isn't processed in time. For example, GDB sends vCont;c and
interrupt (see gdb.base/interrupt-noterm.exp), we'll resume the
inferior and wait once packet vCont;c is seen. If we don't check the
interrupt character after vCont;c packet, interrupt character will stay
in the buffer unattended until GDBserver returns from the wait, which
may take a while. Note that since we've read '\003' from file
descriptor, SIGIO signal handler input_interrupt doesn't help either.
This issue can be exposed by hacking the end of getpkt like
@@ -1041,6 +1050,9 @@ getpkt (char *buf)
}
}
+ if (readchar_bufcnt > 0)
+ gdb_assert (*readchar_bufp != '\003');
+
return bp - buf;
}
and this can trigger internal error,
(gdb) PASS: gdb.base/interrupt-noterm.exp: interrupt
Remote connection closed^M
(gdb) FAIL: gdb.base/interrupt-noterm.exp: inferior received SIGINT
Remote debugging from host 10.2.206.40^M
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/remote-utils.c:1054: A problem internal to GDBserver has been detected.^M
getpkt: Assertion `*readchar_bufp != '\003'' failed.^M
This patch is to peek the buffer, if it is '\003', consume it and call
*the_target->request_interrupt.
gdb/gdbserver:
2016-01-26 Yao Qi <yao.qi@linaro.org>
* remote-utils.c (getpkt): If the buffer isn't empty, and the
first character is '\003', call *the_target->request_interrupt.
Use OPTION_MXXX for -mxxx option in x86 assembler.
* config/tc-i386.c (OPTION_OMIT_LOCK_PREFIX): Renamed to ...
(OPTION_MOMIT_LOCK_PREFIX): This.
(md_longopts): Updated.
(md_parse_option): Likewise.
GCC6 will warn about misleading indentation issues like:
gdb/ada-lang.c: In function ‘ada_evaluate_subexp’:
ada-lang.c:11423:9: error: statement is indented as if it were guarded by...
arg1 = unwrap_value (arg1);
^~~~
gdb/ada-lang.c:11421:7: note: ...this ‘else’ clause, but it is not
else
^~~~
In this case it would be a bug except for the fact the if clause already
returned early. So this misindented statement really only got executed
for the else case. But it could easily mislead a reader, so adding a
proper else block is the correct solution.
In case of c-typeprint.c (c_type_print_base) the if statement is indeed
misleadingly indented, but not a bug. Just indent correctly. The inflow.c
(terminal_ours_1) misindented block comes from the removal of an if clause
in commit d9d2d8b which looks correct. Just introduce an else to fixup the
indentation of the block. The linux-record.c misleadingly indented return
statements are just that. Misleading to the reader, but not actual bugs.
Just unindent them so they don't look like they fall under the wrong if
clause.
