Hi,
I happen to see that field need_step_over in struct lwp_info is only
used to print a debug info. need_step_over is set in linux_wait_1
when breakpoint_here is true, however, we check breakpoint_here too in
need_step_over_p and do the step over. I think we don't need field
need_step_over, and check breakpoint_here directly in need_step_over_p.
This field was added in this patch
https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code
wasn't changed much since then.
This patch is to remove it.
gdb/gdbserver:
2016-04-28 Yao Qi <yao.qi@linaro.org>
* linux-low.h (struct lwp_info) <need_step_over>: Remove.
* linux-low.c (linux_wait_1): Update.
(need_step_over_p): Likewise.
PR target/19722
opcodes * aarch64-dis.c (aarch64_opcode_decode): Run verifier if present.
* aarch64-opc.c (verify_ldpsw): New function.
* aarch64-opc.h (verify_ldpsw): New prototype.
* aarch64-tbl.h: Add initialiser for verifier field.
(LDPSW): Set verifier to verify_ldpsw.
binutils* testsuite/binutils-all/aarch64/illegal.s: New test.
* testsuite/binutils-all/aarch64/illegal.d: New test driver.
include * opcode/aarch64.h (struct aarch64_opcode): Add verifier field.
Since not all ELF targets use the elf.em emulation to support ld option:
--compress-debug-sections=zlib-gnu, limit compressed1b.d to Linux/GNU
targets.
* testsuite/ld-elf/compressed1b.d: Only run for Linux/GNU targets.
This patch makes gdb_load_shlibs return the destination path of the
copied library. To make the procedure implementation and interface more
straightforward, it also changes it so that it accepts a single shared
library path at the time. Therefore, calls that are passed multiple
libraries:
gdb_load_shlibs $lib1 $lib2
must be changed to separate calls:
gdb_load_shlibs $lib1
gdb_load_shlibs $lib2
A subtle impact is the solib-search-path handling. In the former
version, solib-search-path is set using the directory of the first
passed lib (further calls overwrite the value). In the later version,
the directory of the library passed to the last call to gdb_load_shlibs
remnains. I don't think that's a problem in practice, since if we had
tests that needed multiple different paths in solib-search-path, they
wouldn't work in the first place.
Changed in v2:
* Split behavioural and rename changes in two separate patches.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return
result of gdb_remote_download.
* gdb.base/ctxobj.exp: Split gdb_load_shlibs call.
* gdb.base/dso2dso.exp: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
* gdb.base/print-file-var.exp: Likewise.
* gdb.base/shlib-call.exp: Likewise.
* gdb.base/shreloc.exp: Likewise.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.base/solib-weak.exp (do_test): Likewise.
* gdb.base/unload.exp: Likewise.
With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument
GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.
This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by:
commit e7f0d979dd
Author: Yao Qi <yao@codesourcery.com>
Date: Tue Dec 10 21:59:20 2013 +0800
Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10 Yao Qi <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0
gdb/ChangeLog
2016-04-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.
Skip debug sections when estimating distances between output sections
since compressed_size is used to compress debug sections and debug
sections aren't excluded from distances between output sections.
bfd/
PR ld/20006
* elf64-x86-64.c (elf_x86_64_convert_load): Skip debug sections
when estimating distances between output sections.
ld/
PR ld/20006
* testsuite/ld-elfvsb/elfvsb.exp (COMPRESS_LDFLAG): New.
(visibility_run): Pass COMPRESS_LDFLAG to visibility_test on
ELF targets.
I get a timeout fail in branch-to-self.exp when it is compiled by a
bare-mental target running qemu, which doesn't have signal.
The test should be skipped if gdb,nosignals exists, and that is
what this patch does.
gdb/testsuite:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/branch-to-self.exp: Skip it if gdb,nosignals
exists.
Currently c_value_print will turn struct reference values into pointers before
doing a set of RTTI checks. This was introduced as a fix to PR c++/15401.
If there's RTTI the pointer will be adjusted and converted back to a reference.
However, if there's no RTTI the value will still be treated as a pointer during
the remainder of the function.
This patch moves the conversion down so that it's always performed when needed.
Notice this currently has not user-visible effects, so can be seen as a small
code cleanup. However, it'll be necessary for the bug-fix for handling
synthetic C++ references. It causes no testsuite regressions.
gdb/ChangeLog:
2016-04-26 Martin Galvan <martin.galvan@tallertechnologies.com>
* c-valprint.c (c_value_print): Always convert val back to reference
type if we converted it to a pointer type.
Hi,
command "tfind" will find the first trace snapshot if no trace
snapshot is selected, but this behavior isn't documented.
This patch completes the doc of command "tfind" without argument.
gdb/doc:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (tfind): Complete doc about tfind without
argument.
In some babeltrace versions before 1.2.0, the header file iterator.h
declares the enum values `BT_SEEK_*' within the struct declaration of
bt_iter_pos. The enum values are supposed to be globally-scoped, which
works for C, but not for C++. Later babeltrace versions declare the
enum outside the struct:
https://lists.lttng.org/pipermail/lttng-dev/2013-September/021411.html
Now that GDB is compiled with C++, the GDB build fails on a system with
an affected babeltrace version: the compiler complains about a missing
declaration of BT_SEEK_BEGIN in ctf.c.
This patch enhances the configure check to recognize such babeltrace
versions as unusable for GDB.
gdb/ChangeLog:
* configure.ac: Enhance configure check for babeltrace to reject
non-C++-enabled versions.
* configure: Regenerate.
Since ld may generate compressed debug sections by default, pass
--compress-debug-sections=none to ld to avoid compressed debug
sections.
* ld-elf/compressed1b.d: Pass --compress-debug-sections=none
to ld.
* ld-elf/compressed1c.d: Likewise.
include/
* bfdlink.h (struct bfd_link_hash_entry): Add "section" field to
undef. Formatting.
bfd/
* elflink.c (_bfd_elf_is_start_stop): New function.
(_bfd_elf_gc_mark_rsec): Use it.
* elf-bfd.h (_bfd_elf_is_start_stop): Declare.
arithmetic on void * is undefined in ISO C, so we should avoid it. In
GNU C sizeof void * is defined as 1, and that is pretty clearly what
this code wants, so change it to do arithmetic on bfd_byte *.
Unfortunately most of the argument types come from virtual function
interfaces so changing the types to bfd_byte * isn't trivial though it
might make the code clearer. So for the moment its easiest to leave the
variable types as void * and cast before doing arithmetic.
bfd/ChangeLog:
2016-04-26 Trevor Saunders <tbsaunde+binutils@tbsaunde.org>
* elf32-rx.c (rx_set_section_contents): Avoid arithmetic on void *.
* mmo.c (mmo_get_section_contents): Likewise.
(mmo_set_section_contents): Likewise.
Instead of pre-computing indices into a fortran array re-use
the value_* interfaces to subscript a fortran array.
The benefit of using the new interface is that it takes care of
dynamic types and resolve them when needed.
This fixes issues when printing structures with dynamic arrays from toplevel.
Before:
(gdb) p twov
$1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ...
After:
(gdb) p twov
$1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ...
2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-valprint.c (f77_create_arrayprint_offset_tbl): Remove
function.
(F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro.
(f77_print_array_1): Use value_subscript to subscript a
value array.
(f77_print_array): Remove call to f77_create_arrayprint_offset_tbl.
(f_val_print): Use value_field to construct a field value.
gdb/testsuite/Changelog:
* vla-type.exp: Print structure from toplevel.
Resolve type of an array's element to be printed in case it is dynamic.
Otherwise we don't use the correct boundaries nor the right location.
Before:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408)
End Type one :: tone
End Type five
After:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(2,4,6)
End Type one :: tone
End Type five
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* valarith.c (value_address): Resolve dynamic types.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: Add test for static and dynamic arrays
of dynamic types.
* gdb.fortran/vla-type.exp: Add test for static and dynamic arrays
of dynamic types.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
There is an unused NULL entry at the head of dynamic symbol table which
we must account for in our count even if the table is empty or unused
since it is intended for the mandatory DT_SYMTAB tag (.dynsym section)
in .dynamic section.
* elf-bfd.h (elf_link_hash_table): Update comments for
dynsymcount.
* elflink.c (_bfd_elf_link_renumber_dynsyms): Always count for
the unused NULL entry at the head of dynamic symbol table.
(bfd_elf_size_dynsym_hash_dynstr): Remove dynsymcount != 0
checks.
When GDBserver steps over a breakpoint using software single step, it
enqueues the signal, single step and deliver the signal in the next
resume if step over is not needed. In this way, the program won't
receive the signal if the conditional breakpoint is set a branch to
self instruction, because the step over is always needed.
This patch removes the restriction that don't deliver the signal to
the inferior if we are trying to reinsert a breakpoint for software
single step and change the decision on resume vs. step-over when the
LWP has pending signals to deliver.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Adjust.
(need_step_over_p): Return zero if the LWP has pending signals
can be delivered on software single step target.
GDBserver steps over a breakpoint while the single step breakpoint
is inserted at the same address, there are two breakpoint objects
using single raw breakpoint, which is inserted (for single step).
When step over is finished, GDBserver reinsert the breakpoint, but
it finds the raw breakpoint is already inserted, and error out
"Breakpoint already inserted at reinsert time." Even if I change the
order to delete reinsert breakpoints first (which only decreases the
refcount, but leave inserted flag unchanged), the error is still
there.
The fix is to remove the error and return instead.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (reinsert_raw_breakpoint): If bp->inserted is true
return instead of error.
When GDBserver inserts a breakpoint, it looks for raw breakpoint, if
the raw breakpoint is found, increase its refcount, and return. This
doesn't work when it steps over a breakpoint using software single
step and the underneath instruction of breakpoint is branch to self.
When stepping over a breakpoint on ADDR using software single step,
GDBserver uninsert the breakpoint, so the corresponding raw breakpoint
RAW's 'inserted' flag is zero. Then, GDBserver insert single step
breakpoint at the same address ADDR because the instruction is branch
to self, the same raw brekapoint RAW is found, and increase the
refcount. However, the raw breakpoint is not inserted, and the
program won't stop.
gdb/gdbserver:
2016-04-25 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
* mem-break.c (set_raw_breakpoint_at): Create a raw breakpoint
object. Insert it if it is not inserted yet. Increase the
refcount and link it into the proc's raw breakpoint list.
GDB doesn't insert software single step breakpoint if the instruction
branches to itself, so that the program can't stop after command "si".
(gdb) b 32
Breakpoint 2 at 0x8680: file git/gdb/testsuite/gdb.base/branch-to-self.c, line 32.
(gdb) c
Continuing.
Breakpoint 2, main () at gdb/git/gdb/testsuite/gdb.base/branch-to-self.c:32
32 asm (".Lhere: " BRANCH_INSN " .Lhere"); /* loop-line */
(gdb) si
infrun: clear_proceed_status_thread (Thread 3991.3991)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 3991.3991] for step-over
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,8678,4#f3...Packet received: OK
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,b6fe86c8,4#82...Packet received: OK
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 3991.3991] at 0x868
breakpoint.c:should_be_inserted thinks the breakpoint shouldn't be
inserted, which is wrong. This patch restrict the condition that
only skip the non-single-step breakpoints if they are inserted at
the place we are stepping over, however we don't want to skip
single-step breakpoint if its thread is the thread we are stepping
over, so in this patch, I add a thread num in 'struct step_over_info'
to record the thread we're stepping over.
gdb:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (should_be_inserted): Return 0 if the location's
owner is not single step breakpoint or single step breakpoint's
thread isn't the thread which is stepping past a breakpoint.
* gdbarch.sh (software_single_step): Update comments.
* gdbarch.h: Regenerated.
* infrun.c (struct step_over_info) <thread>: New field.
(set_step_over_info): New argument 'thread'. Callers updated.
(clear_step_over_info): Set field thread to -1.
(thread_is_stepping_over_breakpoint): New function.
* infrun.h (thread_is_stepping_over_breakpoint): Declaration.
Disassembler won't work properly when size of bfd_vma is smaller than
address size.
PR binutils/19983
PR binutils/19984
* i386-dis.c (print_insn): Return -1 if size of bfd_vma is
smaller than address size.
gdb/ChangeLog
* ppc-linux-nat.c (ppc_linux_read_description): Use PPC_FEATURE_HAS_VSX
and PPC_FEATURE_HAS_ALTIVEC to check if such features are available.
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux,
like this,
print derived_whole^M
$43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole
print derived_whole^M
$47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole
these fails are also found by recent x86_64-linux buildbot,
https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html
The fix is exactly the same as this one
http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the
extra "VTT" after hex), in which we match extra things after $hex.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match
more after $hex.
Before this patch
https://sourceware.org/ml/gdb-patches/2014-02/msg00709.html
read_value_memory checks parameter 'stack', and call read_stack or
read_memory respectively. However, 'stack' is not checked and
TARGET_OBJECT_MEMORY is always used in target_xfer_partial, which is
a mistake in the patch above.
This patch checks parameter 'stack', and choose TARGET_OBJECT_MEMORY
or TARGET_OBJECT_STACK_MEMORY accordingly.
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* valops.c (read_value_memory): New local variable 'stack'.
Set it to either TARGET_OBJECT_STACK_MEMORY or
TARGET_OBJECT_MEMORY.
This factors out all the yy-variables remapping to a single file,
instead of each parser having to do the same, with different prefixes.
With this, a parser just needs to define the prefix they want and
include yy-remap.h, which does the dirty job.
Note this renames the c_error, ada_error, etc. functions. Writing the
remapping pattern as:
#define yyerror GDB_YY_REMAP (error)
instead of:
#define yyerror GDB_YY_REMAP (yyerror)
would have avoided the renaming. However, that would be problematic
if we have a macro 'foo' in scope, when we write:
#define yyfoo GDB_YY_REMAP (foo)
as that would expand 'foo'.
The c_yyerror etc. naming end ups indicating that this is a yacc
related function more clearly, so feels like a good change, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* ada-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* ada-lang.c (ada_language_defn): Adjust.
* ada-lang.h (ada_error): Rename to ...
(ada_yyerror): ... this.
* c-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Adjust.
* c-lang.h (c_error): Rename to ...
(c_yyerror): ... this.
* d-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* d-lang.c (d_language_defn): Adjust.
* d-lang.h (d_error): Rename to ...
(d_yyerror): ... this.
* f-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* f-lang.c (f_language_defn): Adjust.
* f-lang.h (f_error): Rename to ...
(f_yyerror): ... this.
* go-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* go-lang.c (go_language_defn): Adjust.
* go-lang.h (go_error): Rename to ...
(go_yyerror): ... this.
* jv-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* jv-lang.c (java_language_defn): Adjust.
* jv-lang.h (java_error): Rename to ...
(java_yyerror): ... this.
* m2-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* m2-lang.c (m2_language_defn): Adjust.
* m2-lang.h (m2_error): Rename to ...
(m2_yyerror): ... this.
* objc-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* objc-lang.c (objc_language_defn): Adjust.
* opencl-lang.c (opencl_language_defn): Adjust.
* p-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* p-lang.c (pascal_language_defn): Adjust.
* p-lang.h (pascal_error): Rename to ...
(pascal_yyerror): ... this.
* yy-remap.h: New file.
The exceptions-across-readline issue was fixed by the previous commit.
Let's try this again.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_TRY): Remove mention of
the foreign frames issue.
[__cplusplus] (GDB_XCPT): Define as GDB_XCPT_TRY.
If we map GDB'S TRY/CATCH macros to C++ try/catch, GDB breaks on
systems where readline isn't built with exceptions support. The
problem is that readline calls into GDB through the callback
interface, and if GDB's callback throws a C++ exception/error, the
system unwinder won't manage to unwind past the readline frame, and
ends up calling std::terminate(), which aborts the process:
(gdb) whatever-command-that-causes-an-error
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
$
This went unnoticed for so long because:
- the x86-64 ABI requires -fasynchronous-unwind-tables, making it
possible for exceptions to cross readline with no special handling.
But e.g., on ARM or AIX, unless you build readline with
-fexceptions, you trip on the problem.
- TRY/CATCH was mapped to setjmp/longjmp, even in C++ mode, until
quite recently.
The fix is to catch and save any GDB exception that is thrown inside
the GDB readline callback, and then once the callback returns back to
the GDB code that called into readline in the first place, rethrow the
saved GDB exception.
This is similar in spirit to how we catch/map GDB exceptions at the
GDB/Python and GDB/Guile API boundaries.
The next question is then: if we intercept all exceptions within GDB's
readline callback, should we simply return normally to readline? The
callback prototype has no way to signal an error back to readline (*).
The answer is no -- if we return normally, we'll be returning to a
loop inside rl_callback_read_char that continues processing pending
input, calling into GDB again, redisplaying the prompt, etc. Thus if
we want to error out of rl_callback_read_char, we need to long jump
across it, just like we always did before TRY/CATCH were ever mapped
to C++ exceptions.
My first approach built a specialized API to handle this, with a
couple macros to hide the setjmp/longjmp and the struct gdb_exception
saving/rethrowing.
However, I realized that we need to:
- Handle multiple active rl_callback_read_char invocations. If,
while processing input something triggers a secondary prompt, we
end up in a nested rl_callback_read_char call, through
gdb_readline_wrapper.
- Propagate a struct gdb_exception along with the longjmp.
... and that this is exactly what the setjmp/longjmp-based TRY/CATCH
does.
So the fix makes the setjmp/longjmp TRY/CATCH always available under
new TRY_SJLJ/CATCH_SJLJ aliases, even when TRY/CATCH is mapped to C++
try/catch, and then uses TRY_SJLJ/CATCH_SJLJ to propagate GDB
exceptions across the readline callback.
This turns out to be a much better looking fix than my bespoke API
attempt, even. We'll probably be able to simplify TRY_SJLJ/CATCH_SJLJ
when we finally get rid of TRY/CATCH all over the tree, but until
then, this reuse seems quite nice for avoiding a second parallel
setjmp/longjmp mechanism.
(*) - maybe we could propose a readline API change, but we still need
to handle current readline, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (enum catcher_state, struct catcher)
(current_catcher): Define in C++ mode too.
(exceptions_state_mc_catch): Call throw_exception_sjlj instead of
throw_exception.
(throw_exception_sjlj, throw_exception_cxx): New functions,
factored out from throw_exception.
(throw_exception): Reimplement.
* common/common-exceptions.h (exceptions_state_mc_init)
(exceptions_state_mc_action_iter)
(exceptions_state_mc_action_iter_1, exceptions_state_mc_catch):
Declare in C++ mode too.
(TRY): Rename to ...
(TRY_SJLJ): ... this.
(CATCH): Rename to ...
(CATCH_SJLJ): ... this.
(END_CATCH): Rename to ...
(END_CATCH_SJLJ): ... this.
[GDB_XCPT == GDB_XCPT_SJMP] (TRY, CATCH, END_CATCH): Map to SJLJ
equivalents.
(throw_exception): Update comments.
(throw_exception_sjlj): Declare.
* event-top.c (gdb_rl_callback_read_char_wrapper): Extend intro
comment. Wrap body in TRY_SJLJ/CATCH_SJLJ and rethrow any
intercepted exception.
(gdb_rl_callback_handler): New function.
(gdb_rl_callback_handler_install): Always install
gdb_rl_callback_handler as readline callback.
Use the "gdb_rl_" prefix like other gdb readline function wrappers to
make it clear this is a gdb function, not a readline function.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* event-top.c (rl_callback_read_char_wrapper): Rename to ...
(gdb_rl_callback_read_char_wrapper): ... this.
(change_line_handler, gdb_setup_readline): Adjust.
Bits 20 ~ 23 of CPSR are reserved (RAZ, read as zero), but they are not
zero if the arm program runs on aarch64-linux. AArch64 tracer gets PSTATE
from arm 32-bit tracee as CPSR, but bits 20 ~ 23 are used in PSTATE. I
think kernel should clear these bits when it is read through ptrace, but
the fix in user space is still needed.
This patch fixes these two fails,
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r11, #-12]
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r7]
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* aarch32-linux-nat.c (aarch32_gp_regcache_supply): Clear CPSR
bits 20 to 23.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-aarch32-low.c (arm_store_gregset): Clear CPSR bits 20
to 23.
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
Simple exchange of mpx-avx for avx-mpx.
Other occurrences were not found.
2016-04-22 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/gdbserver/ChangeLog:
* configure.srv (srv_amd64_xmlfiles): Exchange
i386/amd64-mpx-avx.xml for i386/amd64-avx-mpx.xml.
I see the following test fail in arm-linux with -marm and -fomit-frame-pointer,
step
callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27
27 } /* RETURN FROM CALLEE */
(gdb) step
main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58
58 callee(); /* STEP INTO THIS CALL */
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
As we can see, the "step" has already stepped into the function callee,
but in the last line. The second "step" attempts to step to function
body, but it goes out of callee, which isn't expected.
The program is compiled with -marm and -fomit-frame-pointer, the
function callee is prologue-less, because nothing needs to be saved
on stack,
(gdb) disassemble callee
Dump of assembler code for function callee:
0x00010680 <+0>: movw r3, #2364 ; 0x93c
0x00010684 <+4>: movt r3, #2
0x00010688 <+8>: ldr r3, [r3]
0x0001068c <+12>: add r2, r3, #1
0x00010690 <+16>: movw r3, #2364 ; 0x93c
0x00010694 <+20>: movt r3, #2
0x00010698 <+24>: str r2, [r3]
0x0001069c <+28>: mov r3, #0
0x000106a0 <+32>: mov r0, r3
0x000106a4 <+36>: bx lr
program stops at the 0x106a0 (passed the epilogue) after the first
"step". When second "step" is executed, the stepping range is
[0x10680-0x106a0], which starts from the first instruction of function
callee (because it doesn't have prologue).
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 2461.2461.0 [LWP 2461],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x10698^M
infrun: stepping inside range [0x10680-0x106a0]
When program goes out of the range, it stops at the caller of callee,
and test fails. IOW, if function callee has prologue, the stepping
range won't start from the first instruction of the function, and
program stops at the prologue and test passes.
IMO, GDB does nothing wrong, but test shouldn't expect the program
stops in callee after the second "step". I decide to fix test rather
than GDB. In this patch, I change to test to do one "step", and check
the program is still in callee, then, do multiple "step" until program
goes out of the callee.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/step-precsave.exp: Do one step and test program
stops in "callee" and do multiple steps until program goes out
of "callee".
* gdb.reverse/step-reverse.exp: Likewise.
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used. When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.
This behavior gets trouble on conditional breakpoints on branch to
self instruction like this,
0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
and I set breakpoint
$(gdb) break branch-to-self.c:43 if counter > 3
and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.
GDBserver didn't deliver signal when stepping over a breakpoint because
a tracepoint is collected twice if GDBserver does so in the following
scenario, which can be reproduced by gdb.trace/signal.exp.
- program stops at tracepoint, and tracepoint is collected,
- gdbserver starts a step-over,
- a signal arrives, step-over is canceled, and signal should be passed,
- gdbserver starts a new step-over again, pass the signal as well,
- program stops at the entry of signal handler, step-over finished,
- gdbserver proceeds,
- program returns from the signal handler, again to the tracepoint,
and thus is collected again.
The spurious collection isn't that harmful, IMO, so it should be OK
to let GDBserver deliver signal when stepping over a breakpoint.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Don't deliver
signal when stepping over breakpoint with software single
step.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.exp: Also pass if
$tracepoint_hits($i) > $iterations.
Nick Clifton