| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.3.1.DATE-git.
|
|
gdb/ChangeLog:
GDB 8.3.1 released.
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.3.1.
|
|
[ Backport of master commit d806ea2d0e. ]
Currently, no release of GNU Source Highlight supports Rust. However,
I've checked in a patch to do so there, and I plan to make a new
release sometime this summer.
This patch prepares gdb for that by adding support for Rust to the
source highlighting code.
Because Source Highlight will throw an exception if the language is
unrecognized, this also changes gdb to ignore exceptions here. This
will cause gdb to fall back to un-highlighted source text.
This updates gdb's configure script to reject the combination of
Source Highlight and -static-libstdc++. This is done because it's not
possible to use -static-libstdc++ and then catch exceptions from a
shared library.
Tested with the current and development versions of Source Highlight.
gdb/ChangeLog
2019-08-19 Tom Tromey <tom@tromey.com>
PR gdb/25009
* configure: Rebuild.
* configure.ac: Disallow the combination of -static-libstdc++ and
source highlight.
* source-cache.c (get_language_name): Handle rust.
(source_cache::get_source_lines): Ignore highlighting exceptions.
|
|
|
|
|
|
|
|
|
|
[ Backport of master commit d2b584a55b. ]
When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
-re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout. With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.
Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-29 Tom de Vries <tdevries@suse.de>
PR testsuite/25005
* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
|
|
and mention PR breakpoints/24541
|
|
[ Backport of master commit 7d7571f0c1. ]
This bug has been reported on PR breakpoints/24541, but it is possible
to reproduce it easily by running:
make check-gdb TESTS=gdb.base/stap-probe.exp RUNTESTFLAGS='--target_board unix/-m32'
The underlying cause is kind of complex, and involves decisions made
by GCC and the sys/sdt.h header file about how to represent a probe
argument that lives in a register in 32-bit programs. I'll use
Andrew's example on the bug to illustrate the problem.
libstdc++ has a probe named "throw" with two arguments. On i386, the
probe is:
stapsdt 0x00000028 NT_STAPSDT (SystemTap probe descriptors)
Provider: libstdcxx
Name: throw
Location: 0x00072c96, Base: 0x00133d64, Semaphore: 0x00000000
Arguments: 4@%si 4@%di
I.e., the first argument is an unsigned 32-bit value (represented by
the "4@") that lives on %si, and the second argument is an unsigned
32-bit value that lives on %di. Note the discrepancy between the
argument size reported by the probe (32-bit) and the register size
being used to store the value (16-bit).
However, if you take a look at the disassemble of a program that uses
this probe, you will see:
00072c80 <__cxa_throw@@CXXABI_1.3>:
72c80: 57 push %edi
72c81: 56 push %esi
72c82: 53 push %ebx
72c83: 8b 74 24 10 mov 0x10(%esp),%esi
72c87: e8 74 bf ff ff call 6ec00 <__cxa_finalize@plt+0x980>
72c8c: 81 c3 74 e3 10 00 add $0x10e374,%ebx
72c92: 8b 7c 24 14 mov 0x14(%esp),%edi
72c96: 90 nop <----------------- PROBE IS HERE
72c97: e8 d4 a2 ff ff call 6cf70 <__cxa_get_globals@plt>
72c9c: 83 40 04 01 addl $0x1,0x4(%eax)
72ca0: 83 ec 04 sub $0x4,%esp
72ca3: ff 74 24 1c pushl 0x1c(%esp)
72ca7: 57 push %edi
72ca8: 56 push %esi
72ca9: e8 62 a3 ff ff call 6d010 <__cxa_init_primary_exception@plt>
72cae: 8d 70 40 lea 0x40(%eax),%esi
72cb1: c7 00 01 00 00 00 movl $0x1,(%eax)
72cb7: 89 34 24 mov %esi,(%esp)
72cba: e8 61 96 ff ff call 6c320 <_Unwind_RaiseException@plt>
72cbf: 89 34 24 mov %esi,(%esp)
72cc2: e8 c9 84 ff ff call 6b190 <__cxa_begin_catch@plt>
72cc7: e8 d4 b3 ff ff call 6e0a0 <_ZSt9terminatev@plt>
72ccc: 66 90 xchg %ax,%ax
72cce: 66 90 xchg %ax,%ax
Note how the program is actually using %edi, and not %di, to store the
second argument. This is the problem here.
GDB will basically read the probe argument, then read the contents of
%di, and then cast this value to uint32_t, which causes the wrong
value to be obtained. In the gdb.base/stap-probe.exp case, this makes
GDB read the wrong memory location, and not be able to display a test
string. In Andrew's example, this causes GDB to actually stop at a
"catch throw" when it should actually have *not* stopped.
After some discussion with Frank Eigler and Jakub Jelinek, it was
decided that this bug should be fixed on the client side (i.e., the
program that actually reads the probes), and this is why I'm proposing
this patch.
The idea is simple: we will have a gdbarch method, which, for now, is
only used by i386. The generic code that deals with register operands
on gdb/stap-probe.c will call this method if it exists, passing the
current parse information, the register name and its number.
The i386 method will then verify if the register size is greater or
equal than the size reported by the stap probe (the "4@" part). If it
is, we're fine. Otherwise, it will check if we're dealing with any of
the "extendable" registers (like ax, bx, si, di, sp, etc.). If we
are, it will change the register name to include the "e" prefix.
I have tested the patch here in many scenarios, and it fixes Andrew's
bug and also the regressions I mentioned before, on
gdb.base/stap-probe.exp. No regressions where found on other tests.
Comments?
gdb/ChangeLog:
2019-06-27 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/24541
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh: Add 'stap_adjust_register'.
* i386-tdep.c: Include '<unordered_set>'.
(i386_stap_adjust_register): New function.
(i386_elf_init_abi): Register 'i386_stap_adjust_register'.
* stap-probe.c (stap_parse_register_operand): Call
'gdbarch_stap_adjust_register'.
|
|
[ Backport of master commit 677052f2a5. ]
This patch simplifies the code of
stap-probe.c:stap_parse_register_operand by making "regname" an
std::string. No functionality change.
I'm this code's maintainer, so I'm pushing this as it's a fairly
trivial patch.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_register_operand): Make "regname" an
"std::string", simplifying the algorithm.
|
|
[ Backport of master commit b73715df01. ]
When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent. During target_detach
we call linux_nat_target::detach, which:
However, during the second step we run into this code in
stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:
...
gdb_assert (lwp_is_stopped (lwp));
...
The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit. There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.
The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.
The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.
Tested on x86_64-linux, using native and native-gdbserver.
gdb/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
|
|
[ Backport of commit 766f883622. ]
Calls to error () can cause SIGTTOU to send gdb to the background.
For example, on an Arm build:
(gdb) b main
Breakpoint 1 at 0x10774: file /build/gdb/testsuite/../../../src/binutils-gdb/gdb/testsuite/gdb.base/watchpoint.c, line 174.
(gdb) r
Starting program: /build/gdb/testsuite/outputs/gdb.base/watchpoint/watchpoint
[1]+ Stopped ../gdb ./outputs/gdb.base/watchpoint/watchpoint
localhost$ fg
../gdb ./outputs/gdb.base/watchpoint/watchpoint
Cannot parse expression `.L1199 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
The SIGTTOU is raised whilst inside a syscall during the call to tcdrain.
Fix is to use scoped_ignore_sigttou to ensure SIGTTOU is blocked.
In addition fix include comments - job_control is not included via terminal.h
gdb/ChangeLog:
* event-top.c: Remove include comment.
* inflow.c (class scoped_ignore_sigttou): Move from here...
* inflow.h (class scoped_ignore_sigttou): ...to here.
* ser-unix.c (hardwire_drain_output): Block SIGTTOU during drain.
* top.c: Remove include comment.
|
|
[ Backport of master commit ea142fbfc9. ]
When a binary is built using PIE, reloading the file will cause GDB to error
on restart. For example:
gdb ./a.out
(gdb) break main
(gdb) run
(gdb) file ./a.out
(gdb) continue
Will cause GDB to error with:
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x9e0
Command aborted.
This is due to the symbol offsets not being relocated after reloading the file.
Fix is to ensure solib_create_inferior_hook is called, in the same manner as
infrun.c:follow_exec().
Expand the idempotent test to cover PIE scenarios.
gdb/ChangeLog:
* symfile.c (symbol_file_command): Call solib_create_inferior_hook.
gdb/testsuite/ChangeLog:
* gdb.base/break-idempotent.exp: Test both PIE and non PIE.
|
|
[ Backport of master commit 968aa7ae38. ]
Recent versions of Ubuntu and Debian default GCC to enable pie.
In dump.exp, pie will causes addresses to be out of range for IHEX.
In break-interp.exp, pie is explicitly set for some tests and assumed
to be disabled for the remainder.
Ensure pie is disabled for these tests when required.
In addition, add a pie option to gdb_compile to match the nopie option
and simplify use.
gdb/testsuite/ChangeLog:
* README: Add pie options.
* gdb.base/break-interp.exp: Ensure pie is disabled.
* gdb.base/dump.exp: Likewise.
* lib/gdb.exp (gdb_compile): Add pie option.
|
|
[ Backport of master commit 3d507ff23b. ]
Pedro pointed out an issue in the cp_print_value_fields
patch, aka the fix for PR c++/20020.
This patch addresses the issue. Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-06-27 Tom Tromey <tromey@adacore.com>
* gdb.cp/constexpr-field.exp: Use setup_xfail.
|
|
[ Backport of master commit 4330d61dfb. ]
PR c++/20020 concerns a crash in cp_print_value_fields. The immediate
cause is that cp_print_value_fields does not handle the case where
value_static_field fails. This is fixed in this patch by calling
cp_print_static_field from the "try" block.
Digging a bit deeper, the error occurs because GCC does not emit a
DW_AT_const_value for a static constexpr member appearing in a
template class. I've filed a GCC bug for this.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* cp-valprint.c (cp_print_value_fields): Call
cp_print_static_field inside "try".
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* gdb.cp/constexpr-field.exp: New file.
* gdb.cp/constexpr-field.cc: New file.
|
|
[ Backport of master commit e99f9db0f5. ]
The commit "[gdb/symtab] Fix language of duplicate static minimal symbol"
introduces a performance regression, when loading a cc1 executable build with
-O0 -g and gcc 7.4.0. The performance regression, measured in 'real' time is
about 175%.
The slower execution comes from the fact that the fix in symbol_set_names
makes the call to symbol_find_demangled_name unconditional.
Fix this by reverting the commit, and redoing the fix as follows.
Recapturing the original problem, the first time symbol_set_names is called
with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is
not present in the per_bfd->demangled_names_hash hash table, so
symbol_find_demangled_name is called to demangle the name, after which the
mangled/demangled pair is added to the hashtable. The call to
symbol_find_demangled_name also sets gsymbol.language to lang_cplus.
The second time symbol_set_names is called with gsymbol.language == lang_auto
and linkage_name == "_ZL3foov", the name is present in the hash table, so the
demangled name from the hash table is used. However, the language of the
symbol remains lang_auto.
Fix this by adding a field language in struct demangled_name_entry, and using
the field in symbol_set_names to set the language of gsymbol, if necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-06-10 Tom de Vries <tdevries@suse.de>
PR symtab/24545
* symtab.c (struct demangled_name_entry): Add language field.
(symbol_set_names): Revert "[gdb/symtab] Fix language of duplicate
static minimal symbol". Set and use language field.
|
|
[ Backport of master commit e90a813d96. ]
This line of code...
*(int64_t *) ptr = *(int32_t *) ptr;
...in linux-x86-low.c is not needed (and does not work correctly)
within a 32-bit executable. I added an __x86_64__ ifdef (which is
used extensively elsewhere in the file for like purposes) to prevent
this code from being included in 32-bit builds.
It fixes the following regressions when running on native
i686-pc-linux-gnu:
FAIL: gdb.server/abspath.exp: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
FAIL: gdb.server/ext-restart.exp: restart: run to main
FAIL: gdb.server/ext-restart.exp: run to main
FAIL: gdb.server/ext-run.exp: continue to main
FAIL: gdb.server/ext-wrapper.exp: print d
FAIL: gdb.server/ext-wrapper.exp: restart: print d
FAIL: gdb.server/ext-wrapper.exp: restart: run to marker
FAIL: gdb.server/ext-wrapper.exp: run to marker
FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment
FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c
FAIL: gdb.server/run-without-local-binary.exp: run test program until the end
FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
FAIL: gdb.server/server-kill.exp: tstatus
FAIL: gdb.server/server-run.exp: continue to main
gdb/gdbserver/ChangeLog:
PR gdb/24592
* linux-x86-low.c (x86_fill_gregset): Don't compile 64-bit
sign extension code on 32-bit builds.
|
|
[ Backport of master commit 3f52fdbcb5. ]
This commit fixes some failures in gdb.base/interrupt.exp
when debugging a 32-bit i386 linux inferior from an amd64 host.
When running the following test...
make check RUNTESTFLAGS="--target_board unix/-m32 interrupt.exp"
... without this commit, I see the following output:
FAIL: gdb.base/interrupt.exp: continue (the program exited)
FAIL: gdb.base/interrupt.exp: echo data
FAIL: gdb.base/interrupt.exp: Send Control-C, second time
FAIL: gdb.base/interrupt.exp: signal SIGINT (the program is no longer running)
ERROR: Undefined command "".
ERROR: GDB process no longer exists
=== gdb Summary ===
When the test is run with this commit in place, we see 12 passes
instead. This is the desired behavior.
Analysis:
On Linux, when a syscall is interrupted by a signal, the syscall
may return -ERESTARTSYS when a signal occurs. Doing so indicates that
the syscall is restartable. Then, depending on settings associated
with the signal handler, and after the signal handler is called, the
kernel can then either return -EINTR or can cause the syscall to be
restarted. In this discussion, we are concerned with the latter
case.
On i386, the kernel returns this status via the EAX register.
When debugging a 32-bit (i386) process from a 64-bit (amd64)
GDB, the debugger fetches 64-bit registers even though the
process being debugged is 32-bit. Since we're debugging a 32-bit
target, only 32 bits are being saved in the register cache.
Now, ideally, GDB would save all 64-bits in the regcache and
then would be able to restore those same values when it comes
time to continue the target. I've looked into doing this, but
it's not easy and I don't see many benefits to doing so. One
benefit, however, would be that EAX would appear as a negative
value for doing syscall restarts.
At the moment, GDB is setting the high 32 bits of RAX (and other
registers too) to 0. So, when GDB restores EAX just prior to
a syscall restart, the high 32 bits of RAX are zeroed, thus making
it look like a positive value. For this particular purpose, we
need to sign extend EAX so that RAX will appear as a negative
value when EAX is set to -ERESTARTSYS. This in turn will cause
the signal handling code in the kernel to recognize -ERESTARTSYS
which will in turn cause the syscall to be restarted.
This commit is based on work by Jan Kratochvil from 2009:
https://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
Jan's patch had the sign extension code in amd64-nat.c. Several
other native targets make use of this code, so it seemed better
to move the sign extension code to a linux specific file. I
also added similar code to gdbserver.
Another approach is to fix the problem in the kernel. Hui Zhu
tried to get a fix into the kernel back in 2014, but it was not
accepted. Discussion regarding this approach may be found here:
https://lore.kernel.org/patchwork/patch/457841/
Even if a fix were to be put into the kernel, we'd still need
some kind of fix in GDB in order to support older kernels.
Finally, I'll note that Fedora has been carrying a similar patch for
at least nine years. Other distributions, including RHEL and CentOS
have picked up this change and have been using it too.
gdb/ChangeLog:
PR gdb/24592
* amd64-linux-nat.c (amd64_linux_collect_native_gregset): New
function.
(fill_gregset): Call amd64_linux_collect_native_gregset instead
of amd64_collect_native_gregset.
(amd64_linux_nat_target::store_registers): Likewise.
gdb/gdbserver/ChangeLog:
PR gdb/24592
* linux-x86-low.c (x86_fill_gregset): Sign extend EAX value
when using a 64-bit gdbserver.
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.3.0.DATE-git.
|
|
gdb/ChangeLog:
GDB 8.3 released.
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.3.
|
|
Philippe pointed out a styling bug that would occur in some conditions
when paging:
https://sourceware.org/ml/gdb-patches/2019-04/msg00101.html
I was finally able to reproduce this, and this patch fixes the bug.
The problem occurred when text overflowed the line, causing a
pagination prompt, but when no wrap column had been set. In this
case, the current style was reset to show the prompt, but then not
reset back to the previously applied style before emitting the rest of
the line.
The fix is to record the applied style in this case, and re-apply it
afterward -- but only if the pager prompt was emitted, something that
the existing style.exp pointed out on the first, more naive, version
of the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* utils.c (fputs_maybe_filtered): Reset style after paging, even
when no wrap column is set.
|
|
This patch partly reverts commit 8a6d42345 ("Change representation of
psymbol to flush out accessors"); specifically, it changes
partial_symbol to no longer derive from general_symbol_info.
The basic problem here is that the bcache compares objects bitwise,
and this change made it less likely that the relevant fields in the
psymbol would be fully initialized. This could be seen by running a
test under valgrind on the Fedora-i686 buildbot.
I considered a simpler patch, namely just zeroing the psymbol's
"value" field in add_psymbol_to_bcache. However, it wasn't clear to
me that this memset could not then be optimized away by the compiler.
Regression tested by the buildbot. I think this should go in 8.3 as
well.
2019-05-04 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_name_matches, match_partial_symbol)
(lookup_partial_symbol, print_partial_symbols)
(recursively_search_psymtabs, sort_pst_symbols, psymbol_hash)
(psymbol_compare): Update.
(add_psymbol_to_bcache): Clear the entire psymbol.
(maintenance_check_psymtabs): Update.
* psympriv.h (struct partial_symbol): Don't derive from
general_symbol_info.
<obj_section, unrelocated_address, address,
set_unrelocated_address>: Update.
<ginfo>: New member.
* dwarf-index-write.c (write_psymbols, debug_names::insert)
(debug_names::write_psymbols): Update.
|
|
That flavor of MinGW assumes Windows 9X as the default target,
which doesn't expose CONSOLE_FONT_INFO stuff in Windows header
files. Since we no longer support running on Windows older
than XP anyway, requiring it at build time makes sense.
gdb/ChangeLog
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* windows-nat.c [_WIN32_WINNT]: Define _WIN32_WINNT to Windows XP
level, so that various Windows header files expose the necessary
declarations and definitions.
|
|
If you put the separate debug file in a global debug directory, GDB on
MS-Windows would fail to find it. This happens because we obtain the
directory to look up the debug file by concatenating the debug
directory name with the leading directories of the executable, and the
latter includes the drive letter on MS-Windows. So we get an invalid
file name like
d:/usr/lib/debug/d:/usr/bin/foo.debug
This commit fixes that by removing the colon of the drive letter,
thus producing
d:/usr/lib/debug/d/usr/bin/foo.debug
gdb/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* symfile.c (find_separate_debug_file): Remove colon from the
drive spec of DOS/Windows file names of the target, so that the
file name produced from DEBUGDIR and the target's directory will
be valid on DOS/Windows systems.
gdb/doc/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Separate Debug Files): Document how the
subdirectory of the global debug directory is computed on
MS-Windows/MS-DOS.
(cherry picked from commit 5f2459c233faebe8f882e556b2f4a86594a51292)
|
|
We have observed that GDB would randomly trip the following
assertion failure when debugging on Windows. When allowing
the program to run until the inferior exits, we occasionally see:
(gdb) cont
Continuing.
[Thread 48192.0xd100 exited with code 1]
[Thread 48192.0x10ad8 exited with code 1]
[Thread 48192.0x36e28 exited with code 0]
[Thread 48192.0x52be4 exited with code 0]
[Thread 48192.0x5aa40 exited with code 0]
../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
o*, bool): Assertion `thr != nullptr' failed.
Running the same scenario with some additional traces enabled...
(gdb) set verbose
(gdb) set debugevents
... allows us to understand what the issue is. To understand, we need
to first look at the events received when starting the program, and
in particular which threads got created how. First, we get a
CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:
gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)
Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
one of them being for tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
Fast forward a bit of debugging, and we do a "cont" as above,
at which point the programs reaches the end, and the system reports
"exit" events. The first interesting one is the following:
gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)
This is reporting a thread-exit event for a thread whose tid
is the TID of what we call the "main thread". That's the thread
that was created when we received the CREATE_PROCESS_DEBUG_EVENT
notification, and whose TID is actually stored in a global variable
named main_thread_id. This is not something we expected, as
the assumption we made was that the main thread would exit last,
and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
But apparently, this is not always true, at least on Windows Server
2012 and 2016 where this issue has been observed happening randomly.
The consequence of the above notification is that we call
windows_delete_thread for that thread, which removes it from
our list of known threads.
And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
and we can see that the associated tid is not the main_thread_id,
but rather the tid of one of the threads that was created during
the lifetime of the program, in this case tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)
And the debug trace printed right after shows why we're crashing:
[Deleting Thread 317536.0x442a8]
We are trying to delete the thread whose tid=0x442a8, which is
the main_thread_id! As we have already deleted that thread before,
the search for it returns a nullptr, which then trips the assertion
check in delete_thread_1.
This commit fixes this issue. It ignores the open question of
what to do with the main_thread_id global, particularly after
that thread has been removed from our list of threads. This will
be dealt with as a separate patch, to allow cherry-picking
this patch into a release branch.
For now, we fix the code so as to avoid this crash.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
Use current_event.dwThreadId instead of main_thread_id.
|
|
PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.
The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab. This happens because new_symbol decided not to
create a symbol for the particular DIE.
This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.
As mentioned in the bug, I think there are other bugs here. For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter. I didn't research
this too closely, since it seemed more important to fix the crash.
Tested on x86-64 Fedora 29.
I'd like to check this in to the 8.3 branch as well.
gdb/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.
|
|
Allow disabling source-highlight dependency autodetection even
it exists in the system. More details on problem of automatic
dependencies:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
Noticed by Jeroen Roovers in https://bugs.gentoo.org/680238
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
gdb/ChangeLog
2019-04-19 Sergei Trofimovich <siarheit@google.com>
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
|
|
PR symtab/24423 points out that control characters in a source file
cause a hang in the "list" command, a regression introduced by the
styling changes.
This patch, from the PR, fixes the bug. I've included a minimal
change to the "list" test that exercises this code.
I recall that this bug was discussed on gdb-patches, and I thought
there was a patch there as well, but I was unable to find it.
2019-04-19 Ilya Yu. Malakhov <malakhov@mcst.ru>
PR symtab/24423:
* source.c (print_source_lines_base): Advance "iter" when a
control character is seen.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
PR symtab/24423:
* gdb.base/list0.h (foo): Add a control-l character.
|
|
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
Note: when this patch is approved, I will push an equivalent patch
on master, but with TRY/CATCH/e.message () replaced by
try/catch/e.what ().
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
|
|
gdb/ChangeLog:
2019-04-12 Eli Zaretskii <eliz@gnu.org>
* utils.c (prompt_for_continue): Don't restore the styling at the
end, as applied_style has the wrong value. This fixes styling in
long lists of file names that are interrupted by the "Continue?"
prompt.
(cherry picked from commit 51196bbc5618a3741bd7bbed01ac76b25a2e6f9c)
|
|
This commit fixes a regression in the testsuite itself, triggered by
errors being raised from within gdb_test_multiple, originally reported
by Pedro Franco de Carvalho's at
<https://sourceware.org/ml/gdb-patches/2019-03/msg00160.html>. Parts
of the commit message are based on his report.
This started happening due to a commit that was introduced recently,
and it can cause the testsuite to hang.
The commit that triggers this is:
fe1a5cad302b5535030cdf62895e79512713d738
[gdb/testsuite] Log wait status on process no longer exists error
That commit introduces a new "eof" block in gdb_test_multiple. That
is not incorrect itself, but dejagnu's remote_expect is picking that
block as the "default" action when an error is raised from within the
commands inside a call to gdb_test_multiple:
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
#
proc remote_expect { board timeout args } {
I find that "feature" surprising, and I don't really know why it
exists, but this means that the eof section that remote_expect picks
as the error block can be executed even when there was no actual eof
and the GDB process is still running, so the wait introduced in the
commit that tries to get the exit status of GDB hangs forever, while
GDB itself waits for input.
This only happens when there are internal testsuite errors (not
testcase failures). This can be reproduced easily with a testcase
such as:
gdb_start
gdb_test_multiple "show version" "show version" {
-re ".*" {
error "forced error"
}
}
I think that working around this in GDB is useful so that the
testsuite doesn't hang in these cases.
Adding an empty "default" block at the end of the expect body in
gdb_test_multiple doesn't work, because dejagnu gives preference to
"eof" blocks:
if { $x eq "eof" } {
set save_next 1
} elseif { $x eq "default" || $x eq "timeout" } {
if { $error_sect eq "" } {
set save_next 1
}
}
And we do have "eof" blocks. So we need to make sure that the last
"eof" block is safe to use as the default error block. It's also
pedantically incorrect to print
"ERROR: Process no longer exists"
which is what we'd get if the last eof block we have was selected
(more below on this).
So this commit solves this by appending an "eof" with an empty
spawn_id list, so that it won't ever match.
Now, why is the first "eof" block selected today as the error block,
instead of the last one?
The reason is that remote_expect, while parsing the body to select the
default block to execute after an error, is affected by the comments
in the body (since they are also parsed).
If this comment in gdb_test_multiple
# patterns below apply to any spawn id specified.
is changed to
# The patterns below apply to any spawn id specified.
then the second eof block is selected and there is no hang.
Any comment at that same place with an even number of tokens also
works.
This is IMO a coincidence caused by how comments work in TCL.
Comments should only appear in places where a command can appear. And
here, remote_expect is parsing a list of options, not commands, so
it's not unreasonable to not parse comments, similarly to how this:
set a_list {
an_element
# another_element
}
results in a list with three elements, not one element.
The fact that comments with an even number of tokens work is just a
coincidence of how remote_expect's little state machine is
implemented.
I thought we could solve this by stripping out comment lines in
gdb_expect, but I didn't find an easy way to do that. Particularly, a
couple naive approaches I tried run into complications. For example,
we have gdb_test calls with regular expressions that include sequences
like "\r\n#", and by the time we get to gdb_expect, the \r\n have
already been expanded to a real newline, so just splitting the whole
body at newline boundaries, looking for lines that start with #
results in incorrectly stripping out half of the gdb_text regexp. I
think it's better (at least in this commit), to move the comments out
of the list, because it's much simpler and risk free.
gdb/testsuite/ChangeLog:
2019-03-25 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Split appends to $code and
move comments outside list. Append '-i "" eof' section.
(cherry picked from commit 9a93502fa81734d39f213ccb33b497bc40e1423d)
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.91.DATE-git.
|
|
gdb/ChangeLog:
GDB 8.2.91 released.
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.91.
|
|
Changes in DejaGnu 1.6.2 mean that our testsuite will no longer run.
This is because of some confusion over how the gdb.exp file is
handled.
The gdb.exp file is really the tool init file, which is loaded from
within the DejaGnu core, and it should not be loaded directly from any
other file in the testsuite.
DejaGnu tries to prevent the same library being loaded twice by
remembering the names of library files as they are loaded. Until
recently loading the tool init file in DejaGnu was very similar to
loading a library file, as a result, loading the gdb.exp tool init
file simply recorded 'gdb.exp' as having been loaded, future attempts
to load 'gdb.exp' as a library would then be ignored (as the file was
marked as already loaded).
DejaGnu has now changed so that it supports having both a tool init
file and a library with the same name, something that was not possible
before. What this means however is that when the core loads the
'gdb.exp' tool init file it no longer marks the library 'gdb.exp' as
having been loaded. When we then execute 'load_lib gdb.exp' we then
try to reload the 'gdb.exp' file.
Unfortunately our gdb.exp file can only be loaded once. It use of
'rename cd builtin_cd' means that a second attempt to load this file
will fail.
This was discussed on the DejaGnu list here:
http://lists.gnu.org/archive/html/dejagnu/2019-03/msg00000.html
and the suggested advice is that, unless we have some real requirement
to load the tool init file twice, we should remove calls to 'load_lib
gdb.exp' and rely on DejaGnu to load the file for us, which is what
this patch does.
I've tested with native X86-64/GNU Linux and see no regressions.
gdb/testsuite/ChangeLog:
* config/default.exp: Remove 'load_lib gdb.exp'.
* config/monitor.exp: Likewise.
* config/sid.exp: Likewise.
* config/sim.exp: Likewise.
* config/slite.exp: Likewise.
* config/unix.exp: Likewise.
* gdb.base/default.exp: Remove unhelpful comment.
|
|
I noticed that handle_inferior_event is just a small wrapper that
frees the value chain. This patch replaces it with a
scoped_value_mark, reducing the number of lines of code here.
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-20 Tom Tromey <tromey@adacore.com>
PR gdb/24391
* infrun.c (handle_inferior_event): Rename from
handle_inferior_event_1. Create a scoped_value_mark.
(handle_inferior_event): Remove.
|
|
Commit ab42892fb7d2 ("Fix vertical scrolling of TUI source window")
introduced a use-after-free in source_cache::get_source_lines.
At the beginning of the method, we get the fullname of the symtab:
const char *fullname = symtab_to_fullname (s);
fullname points to the string owned by the symtab (s.fullname). When we
later do
scoped_fd desc = open_source_file (s);
s.fullname gets reallocated (even though the string contents may not
change). The fullname local variable now points to freed memory.
To avoid it, refresh the value of fullname after calling
open_source_file.
Here is the ASan report:
$ ./gdb -nx --data-directory=data-directory ./a.out
(gdb) start
Temporary breakpoint 1 at 0x1130: file test.cpp, line 12.
Starting program: /home/simark/build/binutils-gdb/gdb/a.out
Temporary breakpoint 1, main () at test.cpp:12
=================================================================
==26068==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003d4100 at pc 0x7fed89a34681 bp 0x7ffd8d185d80 sp 0x7ffd8d185528
READ of size 2 at 0x6210003d4100 thread T0
#0 0x7fed89a34680 in __interceptor_strlen /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301
#1 0x55b6edf6c2f7 in std::char_traits<char>::length(char const*) /usr/include/c++/8.2.1/bits/char_traits.h:320
#2 0x55b6edf6c9b2 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) /usr/include/c++/8.2.1/bits/basic_string.h:516
#3 0x55b6ef09121b in source_cache::get_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/simark/src/binutils-gdb/gdb/source-cache.c:214
#4 0x55b6ef0a15cb in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1340
#5 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#6 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#7 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#8 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#9 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#10 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#11 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#12 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#13 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#14 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#15 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#16 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#17 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#18 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#19 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#20 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#21 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#22 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#23 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#24 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#25 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#26 0x7fed88ad8222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#27 0x55b6edf4f86d in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x197186d)
0x6210003d4100 is located 0 bytes inside of 4096-byte region [0x6210003d4100,0x6210003d5100)
freed by thread T0 here:
#0 0x7fed89a8ac19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:66
#1 0x55b6edfe12df in xfree<char> /home/simark/src/binutils-gdb/gdb/common/common-utils.h:60
#2 0x55b6edfea675 in gdb::xfree_deleter<char>::operator()(char*) const /home/simark/src/binutils-gdb/gdb/common/gdb_unique_ptr.h:34
#3 0x55b6edfe532c in std::unique_ptr<char, gdb::xfree_deleter<char> >::reset(char*) /usr/include/c++/8.2.1/bits/unique_ptr.h:382
#4 0x55b6edfe7329 in std::unique_ptr<char, gdb::xfree_deleter<char> >::operator=(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /usr/include/c++/8.2.1/bits/unique_ptr.h:289
#5 0x55b6ef09ec2b in find_and_open_source(char const*, char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*) /home/simark/src/binutils-gdb/gdb/source.c:990
#6 0x55b6ef09f56a in open_source_file(symtab*) /home/simark/src/binutils-gdb/gdb/source.c:1069
#7 0x55b6ef090f78 in source_cache::get_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/simark/src/binutils-gdb/gdb/source-cache.c:205
#8 0x55b6ef0a15cb in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1340
#9 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#10 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#11 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#12 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#13 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#14 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#15 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#16 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#17 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#18 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#19 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#20 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#21 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#22 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#23 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#24 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#25 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#26 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#27 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#28 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#29 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
previously allocated by thread T0 here:
#0 0x7fed89a8b019 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7fed88af983f in realpath@@GLIBC_2.3 (/usr/lib/libc.so.6+0x4583f)
#2 0x7fed899dbbbc in __interceptor_canonicalize_file_name /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3297
#3 0x55b6ee376a03 in gdb_realpath(char const*) /home/simark/src/binutils-gdb/gdb/common/pathstuff.c:72
#4 0x55b6ef09ec12 in find_and_open_source(char const*, char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*) /home/simark/src/binutils-gdb/gdb/source.c:990
#5 0x55b6ef09f56a in open_source_file(symtab*) /home/simark/src/binutils-gdb/gdb/source.c:1069
#6 0x55b6ef0a0f12 in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1270
#7 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#8 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#9 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#10 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#11 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#12 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#13 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#14 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#15 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#16 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#17 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#18 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#19 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#20 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#21 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#22 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#23 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#24 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#25 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#26 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#27 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#28 0x7fed88ad8222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
gdb/ChangeLog:
* source-cache.c (source_cache::get_source_lines): Re-read
fullname after calling open_source_file.
|
|
The first time you type UP or DOWN arrow in the command window, GDB
should scroll the source window, but instead it displays the line
number and the file name in the command window(?).
What happens there is that the first time we call
tui_ui_out::do_field_int, it doesn't initialize m_line, because
m_start_of_line is -1, as set by the constructor; and then the
following call to tui_ui_out::do_field_string falls back to
cli_ui_out::do_field_string because m_line is zero.
The problem is caused by a typo in the C++ification of tui_ui_out,
commit 112e8700a6f, where m_line and m_start_of_line's initial values
were swapped from what they used to be:
-struct ui_out *
-tui_out_new (struct ui_file *stream)
+tui_ui_out::tui_ui_out (ui_file *stream)
+: cli_ui_out (stream, 0),
+ m_line (0),
+ m_start_of_line (-1)
{
-
- /* Initialize our fields. */
- data->line = -1;
- data->start_of_line = 0;
This commit fixes it.
gdb/ChangeLog:
2019-03-18 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* tui/tui-out.c (tui_ui_out::tui_ui_out): Fix initialization of
m_line and m_start_of_line.
|
|
gdb/ChangeLog:
2019-03-18 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c (gdb_wgetch): Don't echo CR.
(tui_getc): When gdb_wgetch returns a CR, behave the same as when
it returns a newline. This fixes a regression in TUI mode, whereby
the next line is output on the same screen line as the user input.
(cherry picked from commit b17c4cd078e2d1d8951951016815e474fb133780)
|
|
With styling enabled, I think the way we display the TUI's
highlighted/current line is very ugly and distracting. The problem in
my view is that we reverse foreground/background in colored text as
well, leading to rainbow of background colors.
This patch changes that to something that I find much more sensible --
only reverse the default foreground/background colors, leave styled
text colors alone. If the foreground color is not the default
(because the text was styled), leave the foreground color as is. If
e.g., the terminal is fg=BLACK, and bg=WHITE, and the style wants to
print text in RED, reverse the background color (print in BLACK), but
still print the text in RED.
Note: The new ui_file_style::set_fg method isn't called set_foreground
instead, because set_foreground is a macro in /usr/lib/term.h (ncurses).
gdb/ChangeLog:
2019-03-18 Pedro Alves <palves@redhat.com>
* tui/tui-io.c (reverse_mode_p, reverse_save_bg, reverse_save_fg):
New globals.
(apply_style): New, factored out from ...
(apply_ansi_escape): ... this. Handle reverse video mode.
(tui_set_reverse_mode): New function.
* tui/tui-io.h (tui_set_reverse_mode): New declaration.
* tui/tui-winsource.c (tui_show_source_line): Use
tui_set_reverse_mode instead of setting A_STANDOUT.
* ui-style.h (struct ui_file_style) <set_reverse, set_fg, set_bg>:
New setter methods.
|
|
This commit fixes two issues in scrolling right in the TUI:
#1 - Scrolling right with the arrow keys, the first keypress doesn't
do anything. The problem is that copy_source_line() checks if
(column < first_col), and because of the ++column directly before, it
basically starts with 1 instead of 0.
#2 - Scrolling right handles TABS and escaped characters as single
characters, which just looks weird. The problem is that there's a
spot that misses handling TABS.
gdb/ChangeLog:
2019-03-18 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-source.c (copy_source_line): Fix handling of 'column'.
Handle tabs.
|
|
Without this change, when the current line is longer than the source
window width, redisplaying that line overwrites the window frame and
also portions of the next line.
gdb/ChangeLog:
2019-03-17 Eli Zaretskii <eliz@gnu.org>
* tui/tui-winsource.c (tui_set_is_exec_point_at): Call
tui_refill_source_window instead of tui_refresh_win, to update the
current execution line. This fixes redisplay of the current line
when stepping through very long lines with "next" or "step".
(cherry picked from commit f7f0a12390fc514a5b7b38d1b23397d87532ce05)
|
|
gdb/ChangeLog:
2019-03-16 Eli Zaretskii <eliz@gnu.org>
* source-cache.c (source_cache::get_source_lines): Call
find_source_lines to initialize s->nlines. This fixes vertical
scrolling of TUI source window when the DOWN arrow is pressed.
(cherry picked from commit ab42892fb7d265e72a85e918d4f5c6dfeee3fcd8)
|
|
gdb/ChangeLog:
2019-03-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-winsource.c (tui_show_source_line): Revert "Use
wclrtoeol in tui_show_source_line". This reverts changes made in
commit 4a3045920bbe4e50a0f4920b0fdc4e88ef23015c.
(cherry picked from commit 798e1c302af509c31839c5c3b50c058b61206ee7)
|
|
gdb/ChangeLog:
* NEWS: Combine separate "New targets" sections for 8.3.
|
|
The MS-Windows port of ncurses fails to switch to a color pair if
one or both of the colors are the implicit default colors. This
change records the default colors when TUI is initialized, and
then specifies them explicitly when a color pair uses the default
colors. This allows color styling in TUI mode on MS-Windows.
gdb/ChangeLog:
2019-03-14 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c [__MINGW32__]: Include windows.h. Declare
ncurses_norm_attr.
(tui_initialize_io) [__MINGW32__]: Record the default terminal
colors in ncurses_norm_attr.
(apply_ansi_escape) [__MINGW32__]: If a color in a color pair is
"none", replace it with the default color recorded in
ncurses_norm_attr.
(cherry picked from commit 3fff2c370cd658877be8107bfe9dde8dd0470b46)
|
