| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Correct a commit 2151ccc56c74 ("Always organize test artifacts in a
directory hierarchy") regression causing:
Running .../gdb/testsuite/gdb.arch/mips16-thunks.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
gdb compile failed, mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
UNSUPPORTED: gdb.arch/mips16-thunks.exp: No MIPS16 support in the toolchain.
by using `standard_output_file' to construct output file names
throughout.
gdb/testsuite/
* gdb.arch/mips16-thunks.exp: Use `standard_output_file'
throughout.
|
|
Add hardware breakpoint support for S390 targets.
gdb/ChangeLog:
* s390-linux-nat.c (PER_BIT, PER_EVENT_BRANCH, PER_EVENT_IFETCH)
(PER_EVENT_STORE, PER_EVENT_NULLIFICATION)
(PER_CONTROL_BRANCH_ADDRESS, PER_CONTROL_SUSPENSION)
(PER_CONTROL_ALTERATION): New macros.
(struct s390_debug_reg_state) <break_areas>: New member.
(s390_forget_process): Free break_areas as well.
(s390_linux_new_fork): Copy break_areas as well.
(s390_prepare_to_resume): Install hardware breakpoints.
(s390_can_use_hw_breakpoint): Indicate support for hardware
breakpoints.
(s390_insert_hw_breakpoint, s390_remove_hw_breakpoint): New
linux_nat target methods.
(_initialize_s390_nat): Register them.
gdb/testsuite/ChangeLog:
* lib/gdb.exp: No longer skip hardware breakpoint tests on s390.
|
|
gcc-6.2.1-1.fc26.x86_64
gdb compile failed, /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected primary-expression before 'int'
decltype(int x)
^~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected ')' before 'int'
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:1: error: expected unqualified-id before 'decltype'
decltype(int x)
^~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc: In function 'int main(int, char**)':
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:59:14: error: expected primary-expression before 'decltype'
double y = decltype(2);
^~~~~~~~
'decltype' is a registered keyword since C++11 which is now a default for GCC.
On Thu, 15 Sep 2016 14:06:56 +0200, Pedro Alves wrote:
Seems to be exercising the FLAG_SHADOW bits:
...
{"__typeof__", TYPEOF, OP_TYPEOF, 0 },
{"__typeof", TYPEOF, OP_TYPEOF, 0 },
{"typeof", TYPEOF, OP_TYPEOF, FLAG_SHADOW },
{"__decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX },
{"decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX | FLAG_SHADOW },
...
/* This is used to associate some attributes with a token. */
enum token_flag
{
...
/* If this bit is set, the token is conditional: if there is a
symbol of the same name, then the token is a symbol; otherwise,
the token is a keyword. */
FLAG_SHADOW = 2
};
So perhaps a better fix is to move that particular test to a
separate testcase that force-compiles with -std=c++03.
gdb/testsuite/ChangeLog
2016-09-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.cp/casts.cc (decltype): Move it ...
(main): ... with its call to ...
* gdb.cp/casts03.cc: ... a new file.
* gdb.cp/casts.exp: Add new file casts03.cc, move decltype test to it.
|
|
gcc-6.2.1-1.fc26.x86_64
g++ -std=c++03:
no warnings
g++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:0:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:34: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const float gnu_obj_4::somewhere’ of non-integral type [-fpermissive]
static const float somewhere = 3.14159;
^~~~~~~
clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
1 warning generated.
clang++ -std=c++11:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: error: in-class initializer for static data member of type 'const
float' requires 'constexpr' specifier [-Wstatic-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:3: note: add 'constexpr'
static const float somewhere = 3.14159;
^
constexpr
1 error generated.
OK for check-in?
After the fix out of the 4 combinations above only this one remains non-empty:
clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
1 warning generated.
On Thu, 15 Sep 2016 15:10:50 +0200, Pedro Alves wrote:
Hmm, OK, now that I read the test, I think you were right in trying to
keep it safe, actually. The .exp file has:
if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.everywhere" "\\$\[0-9\].* = 317" "static const int initialized in class definition"
if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.somewhere" "\\$\[0-9\].* = 3.14\[0-9\]*" "static const float initialized in class definition"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Added by this:
https://sourceware.org/bugzilla/show_bug.cgi?id=11702
https://sourceware.org/ml/gdb-patches/2010-06/msg00677.html
https://sourceware.org/ml/gdb-patches/2010-06/txt00011.txt
So the new patch would make that highlighted tested above not
test what its test message says it is testing.
So I now think your original patch is better. Please push
that one instead.
gdb/testsuite/ChangeLog
2016-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.cp/m-static.h (gnu_obj_4::somewhere): Use constexpr for C++11.
|
|
* gdb.arch/powerpc-power.s: Update Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
|
|
There were always various problems with compatibility with ccache:
https://bugzilla.redhat.com/show_bug.cgi?id=488863
https://bugzilla.redhat.com/show_bug.cgi?id=759592
https://sourceware.org/ml/gdb-patches/2009-02/msg00397.html
IMO in a summary ccache finds more a benefit of faster compilation despite the
debug info is no longer exactly the same (as without ccache).
Although for example in this case ccache helped to find a real GDB bug:
https://sourceware.org/ml/gdb-patches/2015-01/msg00497.html
For the GDB testcases ccache has (IMO) no real performance advantage and it
just brings heisenbugs - false FAILs - from time to time:
Breakpoint 1, main () at gdb/testsuite/gdb.base/vdso-warning.c:21^M
21 return 0;^M
(gdb) PASS: gdb.base/vdso-warning.exp: run: startup
->
Breakpoint 1, main () at gdb/testsuite/gdb.base/hbreak-unmapped.c:21^M
21 return 0;^M
(gdb) FAIL: gdb.base/vdso-warning.exp: run: startup
So I find most safe and easy to just disable ccache for all testsuites.
gdb/testsuite/ChangeLog
2016-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* lib/future.exp: Set CCACHE_DISABLE, clear CCACHE_NODISABLE.
|
|
GCC 6's ICF optimization pass is making the declaration of 'm1' and
'm2', on gdb.base/stap-probe.c, to be unified. However, this leads to
only one instance of the probe 'two' being created, which causes a
failure on the testsuite (which expects a multi-location breakpoint to
be inserted on the probe).
This patch fixes this failure by declaring a dummy variable on 'm1',
and using it as an argument to m1's version of probe 'two'. Since we
do not care about the contents of the functions nor about the
arguments of each probe 'two', this is OK.
gdb/testsuite/ChangeLog:
2016-09-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/stap-probe.c (m1): New variable 'dummy', necessary to
make m1's definition to be different from m2's. Use 'dummy' as an
argument for probe 'two'.
|
|
2016-09-10 Jon Beniston <jon@beniston.com>
* lib/mi-support.exp (mi_gdb_target_load): Use target_sim_options
for sim target.
|
|
On various GNU Elf architectures, including AArch64, ARM, s390/s390x,
ppc32/64, and sparc32/64, the dynamic loader passes HWCAP as a parameter
to each ifunc resolver. Currently there is an open glibc Bugzilla that
requests this to be generalized to all architectures:
https://sourceware.org/bugzilla/show_bug.cgi?id=19766
And various ifunc resolvers already rely on receiving HWCAP. Currently
GDB always calls an ifunc resolver without any arguments; thus the
resolver may receive garbage, and based on that, the resolver may decide
to return a function that is not suited for the given platform.
This patch always passes HWCAP to ifunc resolvers, even on systems where
the dynamic loader currently behaves otherwise. The rationale is
that (1) the dynamic loader may get adjusted on those systems as well in
the future; (2) passing an unused argument should not cause a problem
with existing resolvers; and (3) the logic is much simpler without such
a distinction.
gdb/ChangeLog:
* elfread.c (auxv.h): New include.
(elf_gnu_ifunc_resolve_addr): Pass HWCAP to ifunc resolver.
gdb/testsuite/ChangeLog:
* gdb.base/gnu-ifunc-lib.c (resolver_hwcap): New external
variable declaration.
(gnu_ifunc): Add parameter hwcap. Store it in resolver_hwcap.
* gdb.base/gnu-ifunc.c (resolver_hwcap): New global variable.
* gdb.base/gnu-ifunc.exp: Add test to verify that the resolver
received HWCAP as its argument.
|
|
I noticed that if input is already pending on the new-ui TTY, gdb
internal-errors.
E.g., create /dev/pts/2, and type anything there (even just <return>
is sufficient).
Now start GDB creating a new UI on that TTY, while at the same time,
running a synchronous execution command. Something like:
$ gdb program -ex "new-ui console /dev/pts/2" -ex "start"
Back on /dev/pts/2, we get:
(gdb) .../src/gdb/event-top.c:360: internal-error: double prompt
A problem internal to GDB has been detected,
further debugging may prove unreliable.
While the main UI was waiting for "start" to finish, gdb kepts pumping
events, including the input fd of the extra console. The problem is
that stdin_event_handler doesn't restore the current UI back to what
it was, assuming that it's only ever called from the top level event
loop. However, in this case, it's being called from the nested event
loop from within maybe_wait_sync_command_done.
When finally the "start" command is done, we reach the code that
prints the prompt in the main UI, just before starting the main event
loop. Since now the current UI is pointing at the extra console (by
mistake), we find ourselves printing a double prompt on the extra
console. This is caught by the assertion that fails, as shown above.
Since other event handlers also don't restore the UI (e.g., signal
event handlers), I think it's better if whatever is pumping events to
take care to restore the UI, if it cares. That's what this patch
does. New test included.
gdb/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* top.c (wait_sync_command_done): Don't assume current_ui doesn't
change across events. Restore the current UI before returning.
(gdb_readline_wrapper): Restore the current UI before returning.
gdb/testsuite/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui-pending-input.c: New file.
* gdb.base/new-ui-pending-input.exp: New file.
* gdb.exp (clear_gdb_spawn_id): New procedure.
(with_spawn_id): Check whether gdb_spawn_id exists before
referencing it. If gdb_spawn_id didn't exist on entry, clear it
on exit.
|
|
Now that all the prerequisites are in place, this commit finally adds support
for handling the __float128 type on Intel and Power, by providing appropriate
platform-specific versions of the floatformat_for_type callback.
Since at this point we do not yet have any indication in the debug info to
distinguish different floating-point formats of the same length, we simply
use the type name as hint. Types named "__float128" get the IEEE format.
In addition to handling "__float128" itself, we also recognize "_Float128"
and (on Power) "_Float64x", as well as the complex versions of those.
(As pointed out by Joseph Myers, starting with GCC 7, __float128 is just
a typedef for _Float128 -- but it's good to handle this anyway.)
A new test case does some simple verification that the format is decoded
correctly, using both __float128 and "long double" to make sure using both
in the same file still works. Another new test verifies handling of the
_FloatN and _FloatNx types supported by GCC 7, as well as the complex
versions of those types.
Note that this still only supports basic format decoding and encoding.
We do not yet support the GNU extension 'g' suffix for __float128 constants.
In addition, since all *arithmetic* on floating-point values is still
performed in native host "long double" arithmetic, if that format is not
able to encode all target __float128 values, we may get incorrect results.
(To fix this would require implementing fully synthetic target floating-
point arithmetic along the lines of GCC's real.c, presumably using MPFR.)
gdb/ChangeLog:
* i386-tdep.c (i386_floatformat_for_type): New function.
(i386_gdbarch_init): Install it.
* ppc-linux-tdep.c (ppc_floatformat_for_type): New function.
(ppc_linux_init_abi): Install it.
gdb/testsuite/ChangeLog:
* gdb.base/float128.c: New file.
* gdb.base/float128.exp: Likewise.
* gdb.base/floatn.c: Likewise.
* gdb.base/floatn.exp: Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
|
|
Now that init_type no longer takes a FLAGS argument, there is no user of
the TYPE_FLAGS_... enum values left. This commit removes them (and all
references to them in comments as well).
This is mostly a no-op, except for a change to the Python type printer,
which attempted to use them before. (As best as I can tell, this wasn't
really needed anyway, since it was only used to pretty-print type
*instance* flags, which only use the instance flags.)
gdb/ChangeLog:
* gdbtypes.h (enum type_flag_value): Remove.
Remove references to TYPE_FLAG_... in comments throughout.
* gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_...
flags, print the corresponding TYPE_... access macro names.
Remove references to TYPE_FLAG_... in comments throughout.
* infcall.c: Remove references to TYPE_FLAG_... in comments.
* valprint.c: Likewise.
* gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_...
values, only TYPE_INSTANCE_FLAG_... values.
(class TypeFlagsPrinter): Likewise.
gdb/testsuite/ChangeLog:
* gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
|
|
This fixes the problem exercised by Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
This was originally exposed by the OpenJDK Python-based unwinder.
If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory. The recursion happens because:
- get_current_frame() is called soon after the target stops.
- current_frame is NULL, and so we unwind it from the sentinel frame
(which is special and has level == -1).
- We reach get_prev_frame_if_no_cycle, which does cycle detection
based on frame id, and thus tries to compute the frame id of the new
frame.
- Frame id computation requires an unwinder, so we go through all
unwinder sniffers trying to see if one accepts the new frame (the
current frame).
- the unwinder's sniffer calls parse_and_eval().
- parse_and_eval depends on the selected frame/block, and if not set
yet, the selected frame is set to the current frame.
- get_current_frame () is called again. current_frame is still NULL,
so ...
- recurse forever.
In Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself. However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
That "-1" frame level comes from this:
if (catch_exceptions (current_uiout, unwind_to_current_frame,
sentinel_frame, RETURN_MASK_ERROR) != 0)
{
/* Oops! Fake a current frame? Is this useful? It has a PC
of zero, for instance. */
current_frame = sentinel_frame;
}
which is bogus. It's never correct to set the current frame to the
sentinel frame. The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that. And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.
So the fix is to avoid the recursion in the first place.
Observations:
#1 - The recursion happens because we try to do cycle detection from
within get_prev_frame_if_no_cycle. That requires computing the
frame id of the frame being unwound, and that itself requires
calling into the unwinders.
#2 - But, the first time we're unwinding from the sentinel frame,
when we reach get_prev_frame_if_no_cycle, there's no frame chain
at all yet:
- current_frame is NULL.
- the frame stash is empty.
Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.
So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.
But, we can go a little bit further. As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it. This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added. So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.
This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands. I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.
gdb/testsuite/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
|
|
return-nodebug.exp does the test for various types, but we shouldn't
test with floating point type if gdb_skip_float_test returns true.
gdb/testsuite:
2016-09-02 Yao Qi <yao.qi@linaro.org>
* gdb.base/return-nodebug.exp: Skip the test if skip_float_test
is true and $type is "float" or "double".
|
|
We recently found a ARM kernel ptrace bug
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431962.html
Details can be found in the comment in gdb_skip_float_test. We can
skip floating point tests if the kernel bug is detected.
This patch adds more code in gdb_skip_float_test to detect the broken
ptrace on arm-linux. Such detection should be done at the beginning
of the test, because it starts a fresh GDB, so change the test cases
to invoke gdb_skip_float_test at the beginning of test, and use its
return value afterwards.
Since gdb_skip_float_test becomes a gdb_caching_proc, so it can't
have an argument, this patch also removes argument "msg", which isn't
useful.
gdb/testsuite:
2016-09-02 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Skip it if gdb_skip_float_test returns
true.
* gdb.base/call-ar-st.exp: Invoke gdb_skip_float_test.
* gdb.base/call-rt-st.exp: Likewise.
* gdb.base/call-sc.exp: Invoke gdb_skip_float_test and use its
return value instead of gdb,skip_float_test.
* gdb.base/callfuncs.exp: Invoke gdb_skip_float_test.
(do_function_calls): Use its return value instead of
gdb,skip_float_test.
* gdb.base/finish.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/return.exp: Likewise.
* gdb.base/return2.exp: Likewise.
* gdb.base/varargs.exp: Likewise.
* lib/gdb.exp (gdb_skip_float_test): Change it to
gdb_caching_proc. Detect the broken ptrace on arm-linux.
|
|
This inserts missing parentheses in the calculation of the comparison
result between two different inferior numbers. The problem was found by
Philipp Rudo.
gdb/ChangeLog:
* thread.c (tp_array_compar): Insert missing parentheses.
gdb/testsuite/ChangeLog:
* gdb.multi/tids.exp: Test "thread apply all".
|
|
tty^M
(gdb) FAIL: gdb.base/default.exp: tty
gdb/testsuite/ChangeLog
2016-08-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/default.exp (tty): Remove.
|
|
This test case verifies that GDB will not attempt to invoke a python
unwinder recursively.
At the moment, the behavior exhibited by GDB looks like this:
(gdb) source py-recurse-unwind.py
Python script imported
(gdb) b ccc
Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23.
(gdb) run
Starting program: py-recurse-unwind
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[I've shortened pathnames for easier reading.]
The desired / expected behavior looks like this:
(gdb) source py-recurse-unwind.py
Python script imported
(gdb) b ccc
Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23.
(gdb) run
Starting program: py-recurse-unwind
Breakpoint 1, ccc (arg=789) at py-recurse-unwind.c:23
23 }
(gdb) bt
#0 ccc (arg=789) at py-recurse-unwind.c:23
#1 0x00000000004004d5 in bbb (arg=456) at py-recurse-unwind.c:28
#2 0x00000000004004ed in aaa (arg=123) at py-recurse-unwind.c:34
#3 0x00000000004004fe in main () at py-recurse-unwind.c:40
Note that GDB's problems go well beyond the fact that it invokes the
unwinder recursively. In the process it messes up some internal state
(the frame stash) leading to display of (only) the sentinel frame in
the backtrace.
gdb/testsuite/ChangeLog:
* gdb.python/py-recurse-unwind.c: New file.
* gdb.python/py-recurse-unwind.py: New file.
* gdb.python/py-recurse-unwind.exp: New file.
|
|
This patch allows the user to set the inferior-tty to "empty", in order
to come back to the default behaviour of using the same tty as gdb is
using.
This is already supported in MI (and tested in gdb.mi/mi-basics.exp).
I added a new test, set-inferior-tty.exp, where I test only the setting
and unsetting of the parameter. It would be nice to actually test that
the inferior output properly goes to the separate tty, but that will be
for another day.
gdb/ChangeLog:
* infcmd.c (set_inferior_io_terminal): Set inferior terminal to
NULL if terminal_name is an empty string.
(_initialize_infcmd): Make the argument of "set inferior-tty"
optional, mention it in the help doc.
gdb/doc/ChangeLog:
* gdb.texinfo (Input/Output): Mention possibility to unset
inferior-tty.
gdb/testsuite/ChangeLog:
* gdb.base/set-inferior-tty.exp: New file.
* gdb.base/set-inferior-tty.c: New file.
|
|
This patch fixes a problem that problem triggers if you start an
inferior, e.g., with the "start" command, in a UI created with the
new-ui command, and then run a foreground execution command in the
main UI. Once the program stops for the latter command, typing in the
main UI no longer echoes back to the user.
The problem revolves around this:
- gdb_has_a_terminal computes its result lazily, on first call.
that is what saves gdb's initial main UI terminal state (the UI
associated with stdin):
our_terminal_info.ttystate = serial_get_tty_state (stdin_serial);
This is the state that target_terminal_ours() restores.
- In this scenario, the gdb_has_a_terminal function happens to be
first ever called from within the target_terminal_init call in
startup_inferior:
(top-gdb) bt
#0 gdb_has_a_terminal () at src/gdb/inflow.c:157
#1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217
[...]
#4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456
#5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531
[...]
#7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112
[...]
#9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657
If the command to start the inferior is issued on the main UI, then
readline will have deprepped the terminal when we reach the above, and
the problem doesn't appear.
If however the command is issued on a non-main UI, then when we reach
that gdb_has_a_terminal call, the main UI's terminal state is still
set to whatever readline has sets it to in rl_prep_terminal, which
happens to have echo disabled. Later, when the following synchronous
execution command finishes, we'll call target_terminal_ours to restore
gdb's the main UI's terminal settings, and that restores the terminal
state with echo disabled...
Conceptually, the fix is to move the gdb_has_a_terminal call earlier,
to someplace during GDB initialization, before readline/ncurses have
had a chance to change terminal settings. Turns out that
"set_initial_gdb_ttystate" is exactly such a place.
I say conceptually, because the fix actually inlines the
gdb_has_a_terminal part that saves the terminal state in
set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since
there's no point in making gdb_has_a_terminal do lazy computation.
gdb/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* inflow.c (our_terminal_info, initial_gdb_ttystate): Update
comments.
(enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag):
Delete.
(set_initial_gdb_ttystate): Record our_terminal_info here too,
instead of ...
(gdb_has_a_terminal): ... here. Reimplement in terms of
initial_gdb_ttystate. Make static.
* terminal.h (gdb_has_a_terminal): Delete declaration.
(set_initial_gdb_ttystate): Add comment.
* top.c (show_interactive_mode): Use input_interactive_p instead
of gdb_has_a_terminal.
gdb/testsuite/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* gdb.base/new-ui-echo.c: New file.
* gdb.base/new-ui-echo.exp: New file.
|
|
Hi,
I happen to see gdbserver is spawned like this in gdb.log,
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
as we can see, there are two instances of connect-stopped-target or
connect-stopped-target in the command line spawning gdbserver, but
none of these gets parameters from command line. In these two
tests, gdbserver is spawned via "gdbserver_spawn ${binfile}". However,
the argument of gdbserver_spawn is the argument passed the child
inferior, not the program itself.
# Start a gdbserver process running SERVER_EXEC, and connect GDB
# to it. CHILD_ARGS are passed to the inferior.
#
# Returns the target protocol and socket to connect to.
proc gdbserver_spawn { child_args } {
set target_exec [gdbserver_download_current_prog]
GDBserver gets the program via last_loaded_file, which is set by
gdb_file_cmd. In each test, we don't need to pass ${binfile}.
gdb/testsuite:
2016-08-23 Yao Qi <yao.qi@linaro.org>
* gdb.server/connect-stopped-target.exp (do_test): Pass "" to
gdbserver_spawn.
* gdb.server/connect-without-multi-process.exp (do_test):
Likewise.
|
|
Remote testing isn't considered in signals-state-child.exp, so the it
fails like
shell diff -s /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/gdb.txt^M
diff: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt: No such file or directory^M
(gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
This patch is to fix it.
gdb/testsuite:
2016-08-23 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.exp: Set variables gdb_txt and
standalone_txt. Delete gdb_txt and standalone_txt on host
and target. Spawn the binary on target. Copy files from
target to host.
|
|
Loading a core dump that was either generated on a system running
pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused
set in the environment, solib-svr4.c:svr4_current_sos fails to filter
out the vDSO, resulting in:
(gdb) core-file corefile.core^M
[New LWP 2362]^M
warning: Could not load shared library symbols for linux-vdso.so.1.^M
Do you need "set solib-search-path" or "set sysroot"?^M
Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M
...
The problem is that gdbarch_vsyscall_range does not support core
inferiors at all.
When live debugging, we're finding the vDSO's start address with
auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the
corresponding mapping, by parsing /proc/PID/maps. When debugging a
core dump, we can also determine the starting address from
auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core
mappings out of the host's /proc. But we can instead look for a
corresponding load segment in the core's bfd.
gdb/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* linux-tdep.c (linux_vsyscall_range_raw): For core inferiors,
find the vDSO's start address with AT_SYSINFO_EHDR too, and
determine the vDSO's size by finding the PT_LOAD segment that
matches AT_SYSINFO_EHDR.
gdb/testsuite/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* gdb.base/vdso-warning.exp: Test core dumps too. Use
with_test_prefix. Factor out bits to ...
(test_no_vdso): ... this new procedure.
|
|
This patch fixes an issues with six test suite expect files that do not
run correctly when the test suite is not built in the source directory. The
issue is these tests are not using the current "standard_testfile" call
but rather using the older set command to initialize the "testfile",
"srcfile" and "binprefix" variables or are missing the set for the
"binprefix" variable.
-----------------------------------------------
gdb/testsuite/ChangeLog
2016-08-19 Carl Love <cel@us.ibm.com>
* gdb.arch/altivec-regs.exp: Use standard_testfile instead of
maintaining separate logic for constructing the output path.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.arch/ppc-dfp.exp: Likewise.
* gdb.arch/ppc-fp.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.arch/altivec-abi.exp: Likewise, plus added local variable
binprefix for generating the additional binary files.
|
|
gdb.trace/mi-trace-frame-collected.exp has a couple failures on x32:
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
gdb.log:
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
[...]
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
This test only collects the PC, and thus expects to only see one
register in the output of -trace-frame-collected. However, while on
the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above),
on x32, GDB exposes 32-bit $eip as well, as a pseudo-register
(register 204 above). Thus, collecting $pc/$rip automatically always
collects $eip as well.
gdb/testsuite/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* gdb.trace/mi-trace-frame-collected.exp
(test_trace_frame_collected): On x32, expect two registers.
|
|
gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add "Carl Love".
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
|
|
The GDB testsuite reports 5 test failures on Power 7 instructions.
Additionally the ppc test is missing the new Power 9 instructions as
well as a large number of older instructions. Additionally, some
instruction names have changed or been deleted. This patch
fixes the test failures and completely updates the test to make it
consistent with the supported Power 9 instructions listed in:
gas/testsuite/gas/ppc/power7.d
gas/testsuite/gas/ppc/power8.d
gas/testsuite/gas/ppc/power9.d
gas/testsuite/gas/ppc/altivec.d
gas/testsuite/gas/ppc/altivec2.d
gas/testsuite/gas/ppc/altivec3.d
gas/testsuite/gas/ppc/vsx.d
gas/testsuite/gas/ppc/vsx2.d
gas/testsuite/gas/ppc/vsx3.d
-----------------------------------------------------
gdb/testsuite/ChangeLog
2016-08-18 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
|
|
This error message should not contain the word symbol:
(gdb) remove-inferiors 1
Warning: Can not remove current symbol inferior 1.
gdb/ChangeLog:
* inferior.c (remove_inferior_command): Fix error message.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix
expected error message.
|
|
I noticed that the remove-inferiors command was not tested, and as I am
doing some changes related to the user selection, I want to make sure I
don't break it. For example, I want to make sure it's not possible to
remove the current inferior.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp: New file.
* gdb.multi/remove-inferiors.c: New file.
|
|
I see the following warning when running signals-state-child.exp.
gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args]
fprintf (out, "sigaction={sa_handler=", i);
^
this patch is to remove the argument from fprintf.
gdb/testsuite:
2016-08-12 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.c (main): Remove "i" from fprintf's
argument list.
|
|
Right after a fork is detected, we detach breakpoints from the child
(detach_breakpoints), which calls into target_remove_breakpoint with
inferior_ptid pointing at the child process, but leaves the breakpoint
marked inserted (in the parent).
The problem is that record-full.c always deletes all knowledge of the
breakpoint. Then when we later really delete the breakpoint from the
parent, we fail the assertion, since the breakpoint is unexpectedly
not found in the record-full.c breakpoint table.
The fix is simply to not forget about the breakpoint if we're
detaching it from a fork child.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* record-full.c (record_full_remove_breakpoint): Don't remove the
breakpoint from the record_full_breakpoints VEC if we're detaching
the breakpoint from a fork child.
gdb/testsuite/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* gdb.reverse/waitpid-reverse.exp: Add comment and remove
setup_kfails.
|
|
When executing commands on a secondary UI running the MI interpreter,
some commands that should be synchronous are not. MI incorrectly
continues processing input right after the synchronous command is
sent, before the target stops.
The problem happens when we emit MI async events (=library-loaded,
etc.), and we go about restoring the previous terminal state, we end
up calling target_terminal_ours, which incorrectly always installs the
current UI's input_fd in the event loop... That is, code like this:
old_chain = make_cleanup_restore_target_terminal ();
target_terminal_ours_for_output ();
fprintf_unfiltered (mi->event_channel, "library-loaded");
...
do_cleanups (old_chain);
The fix is to move the add_file_handler/delete_file_handler calls out
of target_terminal_$foo, making these completely no-ops unless called
with the main UI as current UI.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/20418
* event-top.c (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New functions.
(async_enable_stdin): Register input in the event loop.
(async_disable_stdin): Unregister input from the event loop.
(gdb_setup_readline): Register input in the event loop.
* infrun.c (check_curr_ui_sync_execution_done): Register input in
the event loop.
* target.c (target_terminal_inferior): Don't unregister input from
the event loop.
(target_terminal_ours): Don't register input in the event loop.
* target.h (target_terminal_inferior)
(target_terminal_ours_for_output, target_terminal_ours): Update
comments.
* top.h (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New declarations.
* utils.c (ui_unregister_input_event_handler_cleanup)
(prepare_to_handle_input): New functions.
(defaulted_query, prompt_for_continue): Use
prepare_to_handle_input.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20418
* gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files.
* lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
|
|
(-exec-continue, etc.) errors
gdb 7.11 introduced an MI regression: a failing MI sync execution
command misses printing the MI prompt, and then all subsequent command
miss it too:
$ gdb-7.11.1 -i=mi
[...]
p 1
&"p 1\n"
~"$1 = 1"
~"\n"
^done
(gdb) <<< prompted ok
-exec-continue
^error,msg="The program is not being run." <<< missing prompt after this
print 1
&"print 1\n"
~"$2 = 1"
~"\n"
^done <<< missing prompt after this
gdb 7.10.1 behaved correctly, even with "set mi-async on":
-exec-continue
^error,msg="The program is not being run."
(gdb) <<< prompted ok
etc.
Bisecting points at:
commit 0b333c5e7d6c
Author: Pedro Alves <palves@redhat.com>
Date: Wed Sep 9 18:23:23 2015 +0100
Merge async and sync code paths some more
[...]
The problem is that when an exception is thrown, we leave the prompt
state set to PROMPT_BLOCKED, and then mi_execute_command_input_handler
doesn't print the prompt. It used to work because before that patch,
we happened to skip disabling stdin if the current target didn't do
async (which it never does before execution).
I was surprised to find that this bug isn't caught by the testsuite,
so I made a thorough test that tests all combinations of pairs of:
- a failing synchronous execution command
- a failing non-execution command
- a non-failing command
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* mi/mi-main.c (mi_execute_command): Enable input and set prompt
state to PROMPT_NEEDED.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* gdb.mi/mi-cmd-error.exp: New file.
|
|
gdb's (or gdbserver's) own signal handling should not interfere with
the signal dispositions their spawned children inherit. However, it
currently does. For example, some paths in gdb cause SIGPIPE to be
set to SIG_IGN, and as consequence, the child starts with SIGPIPE to
set to SIG_IGN too, even though gdb was started with SIGPIPE set to
SIG_DFL.
This is because the exec family of functions does not reset the signal
disposition of signals that are set to SIG_IGN:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html
Signals set to the default action (SIG_DFL) in the calling process
image are set to the default action in the new process
image. Signals set to be ignored (SIG_IGN) by the calling process
image are set to be ignored by the new process image. Signals set to
be caught by the calling process image are set to the default action
in the new process image (see <signal.h>).
And neither does it reset signal masks or flags.
In order to be transparent, when spawning new child processes to debug
(with "run", etc.), reset signal actions and mask back to what was
originally inherited from gdb/gdbserver's parent, just before execing
the target program to debug.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (SFILES): Add
common/signals-state-save-restore.c.
(HFILES_NO_SRCDIR): Add common/signals-state-save-restore.h.
(COMMON_OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* configure: Regenerate.
* fork-child.c: Include "signals-state-save-restore.h".
(fork_inferior): Call restore_original_signals_state.
* main.c: Include "signals-state-save-restore.h".
(captured_main): Call save_original_signals_state.
* common/common.m4: Add sigaction to AC_CHECK_FUNCS checks.
* common/signals-state-save-restore.c: New file.
* common/signals-state-save-restore.h: New file.
gdb/gdbserver/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* config.in: Regenerate.
* configure: Regenerate.
* linux-low.c: Include "signals-state-save-restore.h".
(linux_create_inferior): Call
restore_original_signals_state.
* server.c: Include "dispositions-save-restore.h".
(captured_main): Call save_original_signals_state.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* gdb.base/signals-state-child.c: New file.
* gdb.base/signals-state-child.exp: New file.
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add new pattern.
|
|
With something like:
struct A { int bitfield:4; } var;
If 'var' ends up wholly-optimized out, printing 'var.bitfield' crashes
gdb here:
(top-gdb) bt
#0 0x000000000058b89f in extract_unsigned_integer (addr=0x2 <error: Cannot access memory at address 0x2>, len=2, byte_order=BFD_ENDIAN_LITTLE)
at /home/pedro/gdb/mygit/src/gdb/findvar.c:109
#1 0x00000000005a187a in unpack_bits_as_long (field_type=0x16cff70, valaddr=0x0, bitpos=16, bitsize=12) at /home/pedro/gdb/mygit/src/gdb/value.c:3347
#2 0x00000000005a1b9d in unpack_value_bitfield (dest_val=0x1b5d9d0, bitpos=16, bitsize=12, valaddr=0x0, embedded_offset=0, val=0x1b5d8d0)
at /home/pedro/gdb/mygit/src/gdb/value.c:3441
#3 0x00000000005a2a5f in value_fetch_lazy (val=0x1b5d9d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3958
#4 0x00000000005a10a7 in value_primitive_field (arg1=0x1b5d8d0, offset=0, fieldno=0, arg_type=0x16d04c0) at /home/pedro/gdb/mygit/src/gdb/value.c:3161
#5 0x00000000005b01e5 in do_search_struct_field (name=0x1727c60 "bitfield", arg1=0x1b5d8d0, offset=0, type=0x16d04c0, looking_for_baseclass=0, result_ptr=0x7fffffffcaf8,
[...]
unpack_value_bitfield is already optimized-out/unavailable -aware:
(...) VALADDR points to the contents of VAL. If the VAL's contents
required to extract the bitfield from are unavailable/optimized
out, DEST_VAL is correspondingly marked unavailable/optimized out.
however, it is not considering the case of the value having no
contents buffer at all, as can happen through
allocate_optimized_out_value.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* value.c (unpack_value_bitfield): Skip unpacking if the parent
has no contents buffer to begin with.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/bitfield-parent-optimized-out.exp: New file.
|
|
PR python/18565 notes that calling frame filters don't work properly for
inlined functions. This happens because Frame.function on an inline
frame will yield the wrong result. This patch changes this code to use
find_frame_funname instead, which handles inline frames properly.
Built and regtested on x86-64 Fedora 24.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* python/py-frame.c (frapy_function): Use find_frame_funname.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* gdb.python/py-frame-inline.exp: Add Frame.function test.
|
|
"single-process" and "multi-process" are used in the test message of
process-dies-while-detaching.exp, but they are misplaced due to
set mode [expr {$multi_process ? "single-process" : "multi-process"}]
This patch is to swap them.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.threads/process-dies-while-detaching.exp (do_test): Set
variable mode to "multi-process" if $multi_process is 1, otherwise
set it to "single-process".
|
|
There are some gdb.cp/ tests fails if the program is compiled for arm
32-bit but GDB/GDBserver is aarch64 64-bit program, because target triplet
doesn't match "arm*-*-*". Instead, we can use is_aarch32_target.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.cp/anon-struct.exp: Check is_aarch32_target.
* gdb.cp/cpexprs.exp: Likewise.
* gdb.cp/m-static.exp: Likewise.
|
|
PR python/20190 arose from an exception I noticed when trying to use
the Python unwinder for Spider Monkey in Firefox.
The problem is that the unwinder wants to examine the value of a
thread-local variable. However, sympy_value rejects this because
symbol_read_needs_frame returns true for a TLS variable.
This problem arose once before, though in a different context:
https://sourceware.org/bugzilla/show_bug.cgi?id=11803
At the time Pedro and Daniel pointed out a simpler way to fix that bug
(see links in 20190 if you are interested); but for this new bug I
couldn't think of a similar fix and ended up implementing Daniel's
other suggestion:
https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html
That is, this patch makes it possible to detect whether a symbol needs
a specific frame, or whether it just needs the inferior to have
registers.
Built and regtested on x86-64 Fedora 24.
2016-07-26 Tom Tromey <tom@tromey.com>
* symtab.c (register_symbol_computed_impl): Update.
PR python/20190:
* value.h (symbol_read_needs): Declare.
(symbol_read_needs_frame): Add comment.
* symtab.h (struct symbol_computed_ops) <read_variable>: Update
comment.
<get_symbol_read_needs>: Rename. Change return type.
* findvar.c (symbol_read_needs): New function.
(symbol_read_needs_frame): Rewrite.
(default_read_var_value): Use symbol_read_needs.
* dwarf2loc.c (struct symbol_needs_baton): Rename.
<needs>: Renamed from needs_frame. Changed type.
(needs_frame_read_addr_from_reg, symbol_needs_get_reg_value)
(symbol_needs_read_mem, symbol_needs_frame_base)
(symbol_needs_frame_cfa, symbol_needs_tls_address)
(symbol_needs_dwarf_call): Rename.
(needs_dwarf_reg_entry_value): Update.
(symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs):
Rename and update.
(locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise.
(dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update.
* defs.h (enum symbol_needs_kind): New.
2016-07-26 Tom Tromey <tom@tromey.com>
PR python/20190:
* gdb.threads/tls.exp (check_thread_local): Add python symbol
test.
|
|
Some btrace tests use assembly source files. They use the target triplet to
distinguish between x86_64 and ia32 ISA. This does not work for -m32 tests
without setting the target triplet to i686-?-?.
Instead use is_amd64_regs_target to distinguish between x86_64 and ia32 ISA.
See also https://sourceware.org/ml/gdb-patches/2016-07/msg00256.html.
testsuite/
* gdb.btrace/record_goto.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/stepi.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall-only.exp: Use is_amd64_regs_target for selecting
assembly source files.
|
|
When a bad interpreter name is passed to new-ui, such as:
(gdb) new-ui bloop /dev/pts/10
A partially created UI is left in the UI list, with interp set to NULL.
Trying to do anything that will print on this UI (such as "start") will
cause a segmentation fault.
Changes in v2:
- Use with_test_prefix to namespace test procedures
- Give an explicit stable test name
- Add a "bad terminal path" test
- Remove useless runto_main
- Add missing intro comments
I did not factor out the pty spawn, as there is some magic involved I
don't quite understand. But it wouldn't bring that much anyway.
gdb/ChangeLog:
* top.h (make_delete_ui_cleanup): New declaration.
* top.c (delete_ui_cleanup): New function.
(make_delete_ui_cleanup): New function.
(new_ui_command): Create restore_ui cleanup earlier, create a
delete_ui cleanup and discard it on success.
gdb/testsuite/ChangeLog:
* gdb.base/new-ui.exp (do_test_invalid_args): New
procedure.
|
|
This patch allows gdbserver to continue recording after disconnect. On
reconnect, the recorded data is accessible to gdb as if no disconnect happened.
A possible application for this feature is remotely examine bugs that occur
at irregular intervals, where maintaining a gdb connection is inconvenient.
This also fixes the issue mentioned here:
https://sourceware.org/ml/gdb-patches/2015-11/msg00424.html
Signed-off-by: Tim Wiederhake <tim.wiederhake@intel.com>
gdb/ChangeLog:
* NEWS: Resume btrace on reconnect.
* record-btrace.c: Added record-btrace.h include.
(record_btrace_open): Split into this and ...
(record_btrace_push_target): ... this.
(record_btrace_disconnect): New function.
(init_record_btrace_ops): Use record_btrace_disconnect.
* record-btrace.h: New file.
* remote.c: Added record-btrace.h include.
(remote_start_remote): Check recording status.
(remote_btrace_maybe_reopen): New function.
gdb/doc/ChangeLog:
* gdb.texinfo: Resume btrace on reconnect.
gdb/testsuite/ChangeLog:
* gdb.btrace/reconnect.c: New file.
* gdb.btrace/reconnect.exp: New file.
Change-Id: I95e8b0ab8a89e58591aba0e63818cee82fd211bc
|
|
Implement support to add catchpoints for a group of related syscalls
using the syntax:
(gdb) catch syscall group:<group>
or
(gdb) catch syscall g:<group>
Several groups are predefined in the xml files for all architectures
supported by GDB over Linux. They are based on the groups defined by
strace.
gdb/
* xml-syscall.c (get_syscalls_by_group): New.
(get_syscall_group_names): New.
(struct syscall_group_desc): New structure to store group data.
(struct syscalls_info): Include field to store the group list.
(sysinfo_free_syscall_group_desc): New.
(free_syscalls_info): Free group list.
(syscall_group_create_syscall_group_desc): New.
(syscall_group_add_syscall): New.
(syscall_create_syscall_desc): Add syscall to its groups.
(syscall_start_syscall): Load group attribute.
(syscall_group_get_group_by_name): New.
(xml_list_syscalls_by_group): New.
(xml_list_of_groups): New.
* xml-syscall.h (get_syscalls_by_group): Export function
to retrieve a list of syscalls filtered by the group name.
(get_syscall_group_names): Export function to retrieve the list
of syscall groups.
* break-catch-syscall.c (catch_syscall_split_args): Verify if
argument is a syscall group and expand it to a list of syscalls
when creating catchpoints.
(catch_syscall_completer): Add word completion for system call
groups.
* configure.ac: Include dependency for xsltproc when building
in maintainer-mode.
* break-catch-syscall.c (_initialize_breakpoint): Update catch
syscall command documentation.
* NEWS: Include section about catching groups of syscalls.
* configure: Regenerate.
* data-directory/Makefile.in: Generate syscall xml when building
in maintainer mode.
* syscalls/gdb-syscalls.dtd: Include group attribute to the
syscall element.
* syscalls/apply-defaults.xsl: New.
* syscalls/linux-defaults.xml.in: New.
* syscalls/aarch64-linux.xml: Rename to aarch64-linux.xml.in.
* syscalls/amd64-linux.xml: Rename to amd64-linux.xml.in.
* syscalls/arm-linux.xml: Rename to arm-linux.xml.in.
* syscalls/bfin-linux.xml: Rename to bfin-linux.xml.in.
* syscalls/i386-linux.xml: Rename to i386-linux.xml.in.
* syscalls/mips-n32-linux.xml: Rename to mips-n32-linux.xml.in.
* syscalls/mips-n64-linux.xml: Rename to mips-n64-linux.xml.in.
* syscalls/mips-o32-linux.xml: Rename to mips-o32-linux.xml.in.
* syscalls/ppc-linux.xml: Rename to ppc-linux.xml.in.
* syscalls/ppc64-linux.xml: Rename to ppc64-linux.xml.in.
* syscalls/s390-linux.xml: Rename to s390-linux.xml.in.
* syscalls/s390x-linux.xml: Rename to s390x-linux.xml.in.
* syscalls/sparc-linux.xml: Rename to sparc-linux.xml.in.
* syscalls/sparc64-linux.xml: Rename to sparc64-linux.xml.in.
* syscalls/aarch64-linux.xml: Regenerate.
* syscalls/amd64-linux.xml: Regenerate.
* syscalls/arm-linux.xml: Regenerate.
* syscalls/i386-linux.xml: Regenerate.
* syscalls/mips-n32-linux.xml: Regenerate.
* syscalls/mips-n64-linux.xml: Regenerate.
* syscalls/mips-o32-linux.xml: Regenerate.
* syscalls/ppc-linux.xml: Regenerate.
* syscalls/ppc64-linux.xml: Regenerate.
* syscalls/s390-linux.xml: Regenerate.
* syscalls/s390x-linux.xml: Regenerate.
* syscalls/sparc-linux.xml: Regenerate.
* syscalls/sparc64-linux.xml: Regenerate.
gdb/testsuite/
* gdb.base/catch-syscall.exp (do_syscall_tests): Add call
to test_catch_syscall_group.
(test_catch_syscall_group): New.
gdb/doc/
* gdb.texinfo (Set Catchpoints): Add 'group' argument to catch
syscall.
|
|
I learned recently that empty struct expressions, like "X{}", have been
promoted from experimental to stable in Rust. This patch changes the
Rust expression parser to allow this case.
New test case included.
Built and regtested on x86-64 Fedora 23, using Rust 1.11 beta.
2016-07-21 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_tuple_struct_type_p): Return false for empty
structs.
* rust-exp.y (struct_expr_list): Allow empty elements.
2016-07-21 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.rs (main): Use empty struct expression.
* gdb.rust/simple.exp: Add tests for empty struct expression.
|
|
I recently see some gdb.server/*.exp fails in my native gdb testing,
in which libexpat isn't available, so GDB isn't able to parse xml file.
It causes gdb.server/ tests fails because GDB can't get registers
correctly from GDBserver.
(gdb) PASS: gdb.server/connect-without-multi-process.exp: multiprocess=off: break main
target remote localhost:2352^M
Remote debugging using localhost:2352^M
warning: Can not parse XML target description; XML support was disabled at compile time^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.17.so.debug from remote target...^M
Reading /lib/.debug/ld-2.17.so.debug from remote target...^M
(no debugging symbols found)...done.^M
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efffbe00000000808d0f4d100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000^
0x4d0f8d80 in _start () from target:/lib/ld-linux-armhf.so.3^M
Without XML support in GDB, it can't parse xml sent by GDBserver, and has
to fall back to the oldest arch. However, GDBserver doesn't know this
(IMO, this is a defect in RSP), and still choose the right target
description to create regcache and 'g' packet. If the port only has
one target description or coincidentally two sides choose the same
target description, there is no such issue. Otherwise, GDB is broken
on read registers.
This patch is to skip gdbserver tests if XML is not support and the
target has multiple target descriptions.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (skip_gdbserver_tests): Return 1
if gdb_skip_xml_test is true on some targets.
|
|
If I run single test solib-list.exp, it is OK. If I run two, as below,
there are fails,
$ make check RUNTESTFLAGS="server-run.exp solib-list.exp"
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
in gdb.log,
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/server-run/server-run /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
server-run is spawned, which is wrong. If I only run solib-list.exp, ld-linux
is spawned, which is right.
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
in test, we spawn gdbserver this way,
# Note we pass ${interp_system}, the program gdbserver spawns, as
# argument here, instead of using gdb_load, because we don't want
# to download the interpreter to the target (it's already there)
# or to the test output directory.
set res [gdbserver_spawn "${interp_system} ${remote_binfile}"]
in gdbserver_spawn -> gdbserver_download_current_prog, if
last_loaded_file is set (when you run multiple tests), it is
returned.
This patch is to unset last_loaded_file in solib-list.exp.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* gdb.server/solib-list.exp: Unset last_loaded_file.
|
|
tested on Fedora 24 x86_64 after:
./configure; make
That is: CFLAGS='-g -O2' CXXFLAGS='-g -O2'
FAIL: gdb.gdb/selftest.exp: unknown source line
FAIL: gdb.gdb/selftest.exp: step into xmalloc call
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add "next over TRY" and
"step into captured_main (args)".
|
|
$ runtest 'CC_FOR_TARGET=gcc -m32' gdb.btrace/tailcall-only.exp
Running ./gdb.btrace/tailcall-only.exp ...
gdb compile failed, tailcall-only.c: Assembler messages:
tailcall-only.c:142: Error: cannot represent relocation type BFD_RELOC_64
[...]
tailcall-only.c:425: Error: cannot represent relocation type BFD_RELOC_64
It works for the other x86 arch combinations:
On Mon, 11 Apr 2016 08:44:23 +0200, Metzger, Markus T wrote:
I'm setting the target triplet to "i686-unknown-linux" in my m32 configuration.
Like this:
set target_triplet "i686-unknown-linux"
set_board_info cflags "-m32"
set_board_info cppflags "-m32"
On Wed, 20 Jul 2016 16:02:20 +0200, Pedro Alves wrote:
There's no reason you should _not_ set it.
But, multilib-style testing with --target_board=unix\{-m64,-m32\} etc.
should work _too_, IMO.
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.btrace/tailcall-only.exp: Use is_lp64_target check.
|
|
(gdb) source /home/jkratoch/redhat/gdb-clean/gdb/testsuite/outputs/gdb.python/py-unwind/py-unwind.py^M
Python script imported^M
Python Exception <type 'exceptions.ValueError'> Bad register: ^M
(gdb) FAIL: gdb.python/py-unwind.exp: import python scripts
class TestUnwinder(Unwinder):
AMD64_RBP = 6
AMD64_RSP = 7
AMD64_RIP = 16
On Tue, 19 Jul 2016 12:06:09 +0200, Yao Qi wrote:
py-unwind.exp does nothing on arch specific thing, so py-unwind.exp shouldn't
be aware of the arch difference, but py-unwind.py should.
On Tue, 19 Jul 2016 20:04:33 +0200, Pedro Alves wrote:
How about we handle this in the .exp file for now and leave something
more complicated for when the test is first ported to some other
arch. WDYT?
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-unwind.exp: Test also ![is_lp64_target].
|
|
A test recently added to gdb.opt/inline-cmds.exp fails for
arm-none-eabi targets because -O2 leads to instructions to be
reordered widely.
I guess it might have made sense years ago to enable optimization in
these tests, but I fail to see the need for that nowadays.
Using -O0 while relying on __attribute__((always_inline)), which is
already used in the tests [1] [2], avoids this sort of trouble, while
still exercising the inlining-related use cases that are the focus of
these tests.
I think that nowadays we can safely assume that all compilers we care
about support __attribute__((always_inline)) or similar.
[1] - Except one spot that missed it.
[2] - Note that the .exp files make sure the frames that should have
been inlined are indeed inlined, with "info frame".
gdb/testsuite/ChangeLog:
2016-07-19 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-break.exp: Remove optimize=-O2.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.opt/inline-cmds.exp: Remove optimize=-O2 and add
additional_flags=-Winline.
* gdb.opt/inline-locals.exp: Likewise.
* gdb.opt/inline-markers.c (ATTR): Define.
(inlined_fn): Use it.
|
