Fix this GDB crash:
$ gdb -ex "set architecture mips:10000"
Segmentation fault (core dumped)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/mips-tdep.c:8436
8436 if (bfd_get_flavour (info.abfd) == bfd_target_elf_flavour
(top-gdb) bt
#0 0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at .../src/gdb/mips-tdep.c:8436
#1 0x00000000007348a6 in gdbarch_find_by_info (info=...) at .../src/gdb/gdbarch.c:5155
#2 0x000000000073563c in gdbarch_update_p (info=...) at .../src/gdb/arch-utils.c:522
#3 0x0000000000735585 in set_architecture (ignore_args=0x0, from_tty=1, c=0x26bc870) at .../src/gdb/arch-utils.c:496
#4 0x00000000005f29fd in do_sfunc (c=0x26bc870, args=0x0, from_tty=1) at .../src/gdb/cli/cli-decode.c:121
#5 0x00000000005fd3f3 in do_set_command (arg=0x7fffffffdcdd "mips:10000", from_tty=1, c=0x26bc870) at .../src/gdb/cli/cli-setshow.c:455
#6 0x0000000000836157 in execute_command (p=0x7fffffffdcdd "mips:10000", from_tty=1) at .../src/gdb/top.c:460
#7 0x000000000071abfb in catch_command_errors (command=0x835f6b <execute_command>, arg=0x7fffffffdccc "set architecture mips:10000", from_tty=1)
at .../src/gdb/main.c:368
#8 0x000000000071bf4f in captured_main (data=0x7fffffffd750) at .../src/gdb/main.c:1132
#9 0x0000000000716737 in catch_errors (func=0x71af44 <captured_main>, func_args=0x7fffffffd750, errstring=0x106b9a1 "", mask=RETURN_MASK_ALL)
at .../src/gdb/exceptions.c:240
#10 0x000000000071bfe6 in gdb_main (args=0x7fffffffd750) at .../src/gdb/main.c:1164
#11 0x000000000040a6ad in main (argc=4, argv=0x7fffffffd858) at .../src/gdb/gdb.c:32
(top-gdb)
We already check whether info.abfd is NULL before all other
bfd_get_flavour calls in the same function. Just this one case was
missing.
(This was exposed by a WIP test that tries all "set architecture ARCH"
values.)
gdb/ChangeLog:
2016-03-07 Pedro Alves <palves@redhat.com>
* mips-tdep.c (mips_gdbarch_init): Check whether info.abfd is NULL
before calling bfd_get_flavour.
I forgot to do it in my previous commit. This is necessary because we
execute the script directly on gdb/testsuite/Makefile.in.
gdb/testsuite/ChangeLog:
2016-03-06 Sergio Durigan Junior <sergiodj@redhat.com>
* analyze-racy-logs.py: Set executable bit.
This is an initial attempt to introduce some mechanisms to identify
racy testcases present in our testsuite. As can be seen in previous
discussions, racy tests are really bothersome and cause our BuildBot
to pollute the gdb-testers mailing list with hundreds of
false-positives messages every month. Hopefully, identifying these
racy tests in advance (and automatically) will contribute to the
reduction of noise traffic to gdb-testers, maybe to the point where we
will be able to send the failure messages directly to the authors of
the commits.
I spent some time trying to decide the best way to tackle this
problem, and decided that there is no silver bullet. Racy tests are
tricky and it is difficult to catch them, so the best solution I could
find (for now?) is to run our testsuite a number of times in a row,
and then compare the results (i.e., the gdb.sum files generated during
each run). The more times you run the tests, the more racy tests you
are likely to detect (at the expense of waiting longer and longer).
You can also run the tests in parallel, which makes things faster (and
contribute to catching more racy tests, because your machine will have
less resources for each test and some of them are likely to fail when
this happens). I did some tests in my machine (8-core i7, 16GB RAM),
and running the whole GDB testsuite 5 times using -j6 took 23 minutes.
Not bad.
In order to run the racy test machinery, you need to specify the
RACY_ITER environment variable. You will assign a number to this
variable, which represents the number of times you want to run the
tests. So, for example, if you want to run the whole testsuite 3
times in parallel (using 2 cores), you will do:
make check RACY_ITER=3 -j2
It is also possible to use the TESTS variable and specify which tests
you want to run:
make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2
And so on. The output files will be put at the directory
gdb/testsuite/racy_outputs/.
After make invokes the necessary rules to run the tests, it finally
runs a Python script that will analyze the resulting gdb.sum files.
This Python script will read each file, and construct a series of sets
based on the results of the tests (one set for FAIL's, one for
PASS'es, one for KFAIL's, etc.). It will then do some set operations
and come up with a list of unique, sorted testcases that are racy.
The algorithm behind this is:
for state in PASS, FAIL, XFAIL, XPASS...; do
if a test's state in every sumfile is $state; then
it is not racy
else
it is racy
(The algorithm is actually a bit more complex than that, because it
takes into account other things in order to decide whether the test
should be ignored or not).
IOW, a test must have the same state in every sumfile.
After processing everything, the script prints the racy tests it could
identify on stdout. I am redirecting this to a file named racy.sum.
Something else that I wasn't sure how to deal with was non-unique
messages in our testsuite. I decided to do the same thing I do in our
BuildBot: include a unique identifier in the end of message, like:
gdb.base/xyz.exp: non-unique message
gdb.base/xyz.exp: non-unique message <<2>>
This means that you will have to be careful about them when you use
the racy.sum file.
I ran the script several times here, and it did a good job catching
some well-known racy tests. Overall, I am satisfied with this
approach and I think it will be helpful to have it upstream'ed. I
also intend to extend our BuildBot and create new, specialized
builders that will be responsible for detecting the racy tests every X
number of days.
2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (DEFAULT_RACY_ITER): New variable.
(CHECK_TARGET_TMP): Likewise.
(check-single-racy): New rule.
(check-parallel-racy): Likewise.
(TEST_TARGETS): Adjust rule to account for RACY_ITER.
(do-check-parallel-racy): New rule.
(check-racy/%.exp): Likewise.
* README (Racy testcases): New section.
* analyze-racy-logs.py: New file.
When calling function with argument of size more than 8 bytes fails with
an error "That operation is not available on integers of more than 8 bytes.".
avr-gdb considers only 8 bytes (sizeof(long long)) in case of passing the
argument in registers. When the argument is of size more than 8 byte
then the utility function to extract bytes failed with the above error.
gdb/
* avr-tdep.c (AVR_LAST_ARG_REGNUM): Define.
(avr_push_dummy_call): Correct last needed argument register.
Write MSB of argument into register and subsequent bytes into
other registers in decreasing order.
ARM process record gets the wrong register number for VMOV (from core
register to single-precision register). That is, we should record
the D register rather than the S pseudo register. The patch also
removes the condition "bit (arm_insn_r->arm_insn, 20)" check, which
has been checked above.
It fixes the following internal error,
(gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main
continue^M
Continuing.^M
../../binutils-gdb/gdb/regcache.c:649: internal-error: regcache_raw_read: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.^M
A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error)
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Simplify the
condition check. Record the right D register number.
This patch removes the printing "Process record does not support",
and do the print by calling arm_record_unsupported_insn in the
caller. Also, call arm_record_extension_space only when condition
is 0xf.
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_extension_space): Remove code
printing "Process record does not support".
(arm_record_data_proc_misc_ld_str): Likewise.
(decode_insn): Call arm_record_extension_space if condition
is 0xf. Call arm_record_unsupported_insn if ret isn't
ARM_RECORD_SUCCESS. Use 'ret' instead of 'insn_id' to hold
the value of thumb2_record_decode_insn_handler.
I found that odd that passing no arguments to feature_to_c.sh produces
this:
$ ./feature_to_c.sh
./feature_to_c.sh: 23: shift: can't shift that many
but passing one argument shows the help:
$ ./feature_to_c.sh hello
Usage: ./feature_to_c.sh OUTPUTFILE INPUTFILE...
This patch changes the script to show the help in both cases.
gdb/ChangeLog:
* features/feature_to_c.sh: Print the help when passing no
argument.
I happen to see that comments to start_step_over isn't in sync with
code, so this patch is to update the comments.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* linux-low.c: Update comments to start_step_over.
This patch adds a new test for stepping over clone syscall.
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (step_over_syscall): Kfail.
Invoke step_over_syscall "clone" and break_cond_on_syscall
"clone".
* gdb.base/step-over-clone.c: New file.
disp-step-syscall.exp is extended for stepping over syscall instruction
in different cases, with or without displaced stepping, and stepping
over by GDBserver.
This patch rename disp-step-syscall.exp to step-over-syscall.exp to
reflect this.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-fork.c: Rename to ...
* gdb.base/step-over-fork.c: ... it. New file.
* gdb.base/disp-step-vfork.c: Rename to ...
* gdb.base/step-over-vfork.c: ... it. New file.
* gdb.base/disp-step-syscall.exp: Rename to ...
* gdb.base/step-over-syscall.exp: ... it. New file.
(disp_step_cross_syscall): Rename to ...
(step_over_syscall): ... it.
We can also extend disp-step-syscall.exp to test GDBserver step over
breakpoint on syscall instruction. That is, we set a breakpoint
with a false condition on syscall instruction, so that GDBserver will
step over it.
This test triggers a GDBserver internal error, which can be fixed by
this series.
(gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns
continue^M
Continuing.^M
Remote connection closed^M
(gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again
In GDBserver, there is an internal error,
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 25554, suspended=-1
the simplified reproducer is like,
$ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork
(gdb) b main
(gdb) c
(gdb) disassemble fork // in order to find the address of insn 'syscall'
....
0x00007ffff7ad6023 <+179>: syscall
(gdb) b *0x00007ffff7ad6023 if main == 0
(gdb) c
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New.
If target supports condition evaluation on target, invoke
break_cond_on_syscall for fork and vfork.
disp-step-syscall.exp was added to test displaced stepping over syscall
instructions, in which we set breakpoint on syscall instruction, and
step over it. In fact, we can extend the test to non-displaced-stepping
case. This patch wraps the test with displaced stepping on and off.
Note that the indentation and format isn't adjusted here to make this
patch easy to read. The following patch will fix the format separately.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp: Don't invoke
support_displaced_stepping.
(disp_step_cross_syscall): Test with displaced stepping off and
on if supported.
This patch moves some code out of disp_step_cross_syscall to a new proc
check_pc_after_cross_syscall and setup. Procedure setup is to start a
fresh GDB and compute the syscall instruction address.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New
proc.
(setup): New proc.
(disp_step_cross_syscall): Move code to check_pc_after_cross_syscall
and setup.
I see the following GDBserver internal error in two cases,
gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 17200, suspended=-1
1. step over a breakpoint on fork/vfork syscall instruction,
2. step over a breakpoint on clone syscall instruction and child
threads hits a breakpoint,
the stack backtrace is
#0 internal_error (file=file@entry=0x44c4c0 "gdb/gdbserver/linux-low.c", line=line@entry=1922,
fmt=fmt@entry=0x44c7d0 "unsuspend LWP %ld, suspended=%d\n") at gdb/gdbserver/../common/errors.c:51
#1 0x0000000000424014 in lwp_suspended_decr (lwp=<optimised out>, lwp=<optimised out>) at gdb/gdbserver/linux-low.c:1922
#2 0x000000000042403a in unsuspend_one_lwp (entry=<optimised out>, except=0x66e8c0) at gdb/gdbserver/linux-low.c:2885
#3 0x0000000000405f45 in find_inferior (list=<optimised out>, func=func@entry=0x424020 <unsuspend_one_lwp>, arg=arg@entry=0x66e8c0)
at gdb/gdbserver/inferiors.c:243
#4 0x00000000004297de in unsuspend_all_lwps (except=0x66e8c0) at gdb/gdbserver/linux-low.c:2895
#5 linux_wait_1 (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, target_options=target_options@entry=0)
at gdb/gdbserver/linux-low.c:3632
#6 0x000000000042a764 in linux_wait (ptid=..., ourstatus=0x665ec0 <last_status>, target_options=0)
at gdb/gdbserver/linux-low.c:3770
#7 0x0000000000411163 in mywait (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, options=options@entry=0, connected_wait=connected_wait@entry=1)
at gdb/gdbserver/target.c:214
#8 0x000000000040b1f2 in resume (actions=0x66f800, num_actions=1) at gdb/gdbserver/server.c:2757
#9 0x000000000040f660 in handle_v_cont (own_buf=0x66a630 "vCont;c:p45e9.-1") at gdb/gdbserver/server.c:2719
when GDBserver steps over a thread, other threads have been suspended,
the "stepping" thread may create new thread, but GDBserver doesn't set
it suspend count to 1. When GDBserver unsuspend threads, the child's
suspend count goes to -1, and the assert is triggered. In fact, GDBserver
has already taken care of suspend count of new thread when GDBserver is
suspending all threads except the one GDBserver wants to step over by
https://sourceware.org/ml/gdb-patches/2015-07/msg00946.html
+ /* If we're suspending all threads, leave this one suspended
+ too. */
+ if (stopping_threads == STOPPING_AND_SUSPENDING_THREADS)
+ {
+ if (debug_threads)
+ debug_printf ("HEW: leaving child suspended\n");
+ child_lwp->suspended = 1;
+ }
but that is not enough, because new thread is still can be spawned in
the thread which is being stepped over. This patch extends the
condition that GDBserver set child's suspend count to one if it is
suspending threads or stepping over the thread.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
PR server/19736
* linux-low.c (handle_extended_wait): Set child suspended
if event_lwp->bp_reinsert isn't zero.
Replace the code which is exactly what enqueue_pending_signal does.
gdb/gdbserver:
2016-03-02 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_resume_one_lwp_throw): Replace code with
enqueue_pending_signal.
Fixes rather embarassing gdb.trace regressions.
gdb/gdbserver/ChangeLog:
* tracepoint.c (cmd_qtstart): Only set ipa_tdesc_idx if agent
is actually loaded.
Printing and resolving of dynamic array's causes sporadic timeout issues on loaded systems.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/vla-history.exp: Lookup array elements and printing exceeds timeout.
Adding a dummy assignment as a new breakpoint anchor because
breakpoint on return statement doesn't work for GCC 5.x.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.cp/vla-cxx.cc: Insert dummy assignment as anchor for an breakpoint.
Nullify pointers to avoid an undefined association status.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.mi/vla.f90: Nullify pointer after declaration.
Add new maintainer to Write After Approval.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
* MAINTAINERS (Write After Approval): Add Bernhard Heckel.
Fixes, on F23:
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c: In function 'gdb_agent_gdb_collect':
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c:50:3: warning: implicit declaration of function 'sleep' [-Wimplicit-function-declaration]
sleep (1);
^
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.trace/ftrace-lock.c: Include <unistd.h>.
This testcase currently fails to compile on Fedora 23:
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c: In function 'start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70:11: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaration]
i = pthread_yield ();
^
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c: In function 'forkoff':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c:114:8: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaratio
n]
i = pthread_yield ();
^
/tmp/ccUkNIsI.o: In function `start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70: undefined reference to `pthread_yield'
(...)
collect2: error: ld returned 1 exit status
UNSUPPORTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: Couldn't compile watchpoint-fork-child.c: unrecognized error
UNTESTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint-fork.exp
testcase .../src/gdb/testsuite/gdb.threads/watchpoint-fork.exp completed i
The glibc manual says, on _GNU_SOURCE:
"You should define these macros by using ‘#define’ preprocessor
directives at the top of your source code files. These directives must
come before any #include of a system header file."
I instead put it in the header all the .c files of the testcase must
include anyway.
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.threads/watchpoint-fork-child.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork-mt.c: Likewise. Don't define
_GNU_SOURCE here.
* gdb.threads/watchpoint-fork-st.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork.h: Define _GNU_SOURCE.
This patch fixes the following error,
ERROR: (/scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step) No such file or directory
FAIL: gdb.arch/arm-disp-step.exp: Can't run to main
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-disp-step.exp: Use standard_testfile and
prepare_for_testing.
When we compile gdb.arch/arm-neon.c with options that don't enable NEON,
there are many error/warnings emitted into gdb.sum, which is annoying.
This patch fixes it by passing quiet to prepare_for_testing.
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Pass quiet to prepare_for_testing.
Since test artifacts are always organized in a directory hierarchy, the
s390-tdbregs test case is not executed correctly any more. This is
because it uses an obsolete way of constructing the executable's path.
This change invokes prepare_for_testing instead.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-tdbregs.exp: Use prepare_for_testing instead of
manually constructing the output path.
This fixes a GDB internal error that may occur when the inferior has no
valid stack pointer in r15.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-stackless.S: New.
* gdb.arch/s390-stackless.exp: New.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_backchain_frame_unwind_cache): Avoid
exception when attempting to access the inferior's backchain.
The last patch supports several syscalls in linux-record.c, so now
GDB aarch64-linux backend can return these canonicalized syscall numbers
per aarch64 syscall number.
This patch fixes the following fails,
Process record and replay target doesn't support syscall number 59^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00000020000eab28 in pipe () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
Process record and replay target doesn't support syscall number 59^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00000020000eab28 in pipe () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/readv-reverse.exp: continue to breakpoint: marker2
gdb:
2016-02-29 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (aarch64_canonicalize_syscall): Support
eventfd2, eventfd2, dup3, inotify_init1, fallocate and pipe2.
Return gdb_sys_epoll_create1 instead of gdb_sys_epoll_create
for aarch64_sys_epoll_create1.
Given two or more modules that import each other's scope, the current symbol
lookup routines would go round in circles looking through each import from
each module, possibly checking the same module twice or more until all possible
paths are marked as "searched".
Given enough modules, this causes an exponential slowdown in time taken to find
symbols that do exist, and infinite recursion when they don't.
gdb/ChangeLog:
* d-namespace.c (d_lookup_symbol_imports): Avoid recursive lookups from
cyclic imports.
gdb/testsuite/ChangeLog:
* gdb.dlang/circular.c: New file.
* gdb.dlang/circular.exp: New file.
This is an obvious patch to fix the following build error seen with
--enable-build-with-cxx:
../../src/gdb/rs6000-tdep.c: In function ‘rs6000_frame_cache* rs6000_frame_cache(frame_info*, void**)’:
../../src/gdb/rs6000-tdep.c:3242:15: error: invalid conversion from ‘void*’ to ‘rs6000_frame_cache*’ [-fpermissive]
return (*this_cache);
~^~~~~~~~~~~~
gdb/ChangeLog
* rs6000-tdep.c (rs6000_frame_cache): Explicitly cast return result
to avoid invalid conversion from void *.
This patch fixes various bugs in arm_record_exreg_ld_st_insn, and use
gdb.reverse/insn-reverse.c to test more arm instructions.
- Set flag SINGLE_REG correctly. In the arch reference manual,
SING_REG is true when the bit 8 of instruction is zero.
- Record the right D registers for instructions changing S registers.
- Fix the order of length and address in record_buf_mem array.
- Shift the offset by 2 instead of by 24.
This patch also fixes one internal error,
(gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main
continue^M
Continuing.^M
../../binutils-gdb/gdb/utils.c:1072: internal-error: virtual memory exhausted.^M
A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error)
gdb:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_exreg_ld_st_insn): Set 'single_reg'
per bit 8. Check bit 20 instead of bit 4 for VMOV
instruction. Record D registers for instructions changing
S registers. Change of the order of length and address
in record_buf_mem array.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/insn-reverse.c [__arm__] (ext_reg_load): New.
[__arm__] (ext_reg_mov, ext_reg_push_pop): New.
(testcases): Update.
When GDB decodes these thumb special data instructions, such as 'mov sp, r7'
the Rd is got incorrectly. According to the arch reference manual, the Rd
is DN:Rdn, in which DN is bit 7 and Rdn is bits 0 to 2. This patch fixes it.
gdb:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (thumb_record_ld_st_reg_offset): Fix the register
number of Rd.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: Rename to ...
* gdb.reverse/insn-reverse.c: ... it.
* gdb.reverse/aarch64.exp: Rename to ...
* gdb.reverse/insn-reverse.exp: ... it.
I said we can generialize gdb.reverse/aarch64.exp for other
architectures https://sourceware.org/ml/gdb-patches/2015-05/msg00482.html
and here is the patch to change aarch64.exp so that it can be used to
test for other architectures as well.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: [__aarch64__] Include arm_neon.h.
(testcase_ftype): New.
(testcases): New array.
(n_testcases): New.
(main): Call each element in testcases.
* gdb.reverse/aarch64.exp: Remove is_aarch64_target check.
(read_testcase): New.
Do the tests in a loop.
Currently, 31-bit gdbserver doesn't support collecting/supplying high
GPRs, VX registers, and TDB data. This is not much of a problem now,
since machines that have them usually have a 64-bit gdbserver that can
be used to debug 31-bit targets just fine. However, with fast
tracepoints, it's not possible to use a 64-bit gdbserver with a 31-bit
IPA (and thus a 31-bit target), so 31-bit gdbserver has to be used
for 31-bit targets. Thus, this patch is needed to allow collecting
high GPRs and VX registers on 31-bit targets via fast tracepoints.
gdb/gdbserver/ChangeLog:
* linux-s390-low.c (s390_num_regs_3264): Define on 31-bit too.
(s390_regmap_3264) [!__s390x__]: New global.
(s390_collect_ptrace_register): Skip map entries containing -1.
(s390_supply_ptrace_register): Ditto.
(s390_fill_gprs_high): New function.
(s390_store_gprs_high): New function.
(s390_regsets): Add NT_S390_HIGH_GPRS.
(s390_get_hwcap): Enable on 31-bit.
(have_hwcap_s390_high_gprs): Enable on 31-bit.
(s390_arch_setup): Enable detection of high GPRs, TDB, VX on 31-bit.
Detect NT_S390_HIGH_GPRS.
(s390_usrregs_info_3264): Enable on 31-bit.
(s390_regs_info): Enable regs_info_3264 on 31-bit.
(initialize_low_arch): Initialize s390_regsets_info_3264 on 31-bit.
This patch removes gdb.base/branches.c which was added by the following
commit, but it is not used at all.
commit ea8122af14
Author: John Metzler <jmetzler@cygnus>
Date: Thu Apr 16 17:56:11 1998 +0000
Thu Apr 16 10:52:34 1998 John Metzler <jmetzler@cygnus.com>
* gdb.base/branches.c: Code with lots of loops and
subroutines. Used to test gdbs ability to single step through PC
changes, especially to test mips-tdep.c:mips_next_pc
gdb/testsuite:
2016-02-25 Yao Qi <yao.qi@linaro.org>
* gdb.base/branches.c: Remove.
If gdbserver and IPA are using different tdesc, they will disagree
about 'R' trace packet size. This results in mangled traces.
To make sure they pick the same tdesc, gdbserver pokes the tdesc
(specified as an index in a target-specific list) into a global
variable in IPA. In theory, IPA could find out the tdesc on its
own, but that may be complex (in particular, I don't know how to
tell whether we have LAST_BREAK on s390 without messing with ptrace),
and we'd have to duplicate the logic.
Tested on i386 and x86_64. On i386, it fixes two FAILs in ftrace.exp.
On x86_64, these failures have been KFAILed - one of them works now,
but the other now fails due to an unrelated reason (ugh).
gdb/gdbserver/ChangeLog:
PR gdb/13808
* Makefile.in: Add i386-*-linux-ipa.o and amd64-*-linux-ipa.o.
* configure.srv: Ditto.
* linux-aarch64-ipa.c (get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment.
* linux-amd64-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_amd64_linux): Remove prototype.
(tdesc_amd64_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-i386-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_i386_linux): Remove prototype.
(tdesc_i386_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-low.c (linux_get_ipa_tdesc_idx): New function.
(linux_target_ops): wire in linux_get_ipa_tdesc_idx.
* linux-low.h (struct linux_target_ops): Add get_ipa_tdesc_idx.
* linux-x86-low.c: Move tdesc declarations to linux-x86-tdesc.h.
(x86_get_ipa_tdesc_idx): New function.
(the_low_target): Wire in x86_get_ipa_tdesc_idx.
* linux-x86-tdesc.h: New file.
* target.h (struct target_ops): Add get_ipa_tdesc_idx.
(target_get_ipa_tdesc_idx): New macro.
* tracepoint.c (ipa_tdesc_idx): New macro.
(struct ipa_sym_addresses): Add addr_ipa_tdesc_idx.
(symbol_list): Add ipa_tdesc_idx.
(cmd_qtstart): Write ipa_tdesc_idx in the target.
(ipa_tdesc): Remove.
(ipa_tdesc_idx): New variable.
(get_context_regcache): Use get_ipa_tdesc.
(gdb_collect): Ditto.
(gdb_probe): Ditto.
* tracepoint.h (get_ipa_tdesc): New prototype.
(ipa_tdesc): Remove.
gdb/testsuite/ChangeLog:
PR gdb/13808
* gdb.trace/ftrace.exp (test_fast_tracepoints): Remove kfail.
We see this error when building with gcc 4.3.
../../gdb/i386-linux-tdep.c: In function ‘i386_linux_handle_segmentation_fault’:
../../gdb/i386-linux-tdep.c:399: error: ‘access’ may be used uninitialized in this function
../../gdb/i386-linux-tdep.c:399: error: ‘upper_bound’ may be used uninitialized in this function
../../gdb/i386-linux-tdep.c:399: error: ‘lower_bound’ may be used uninitialized in this function
It's a false positive, since the variables will always get initialized
in the TRY clause, and the CATCH returns.
gdb/ChangeLog:
* i386-linux-tdep.c (i386_linux_handle_segmentation_fault):
Initialize variables.
The check used hardcoded targets and wasn't doing anything useful anyway,
since unsupported architectures blow up on link due to missing the IPA
library before they ever get to that check.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Remove unnecessary target check.
The PPC64 tracepoint patch added \y at the end of the call_insn pattern -
without that, it embarassed itself and matched the 'bl' in "Dump of
assem*bl*er code for function" as the powerpc call opcode. Since that
sounds like a generally good idea, I've added \y before and after
call_insn for every target. As a result, I had to change x86_64's mnemonic
to 'callq'.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Surround $call_insn with '\y',
change x86_64 call_insn to 'callq'.
When encoding the agent expression operation ax_reg or ax_reg_mask, the
register number used is internal to GDB. However GDBServer expects a tdesc
based number.
This usually does not cause a problem since at the moment, for raw
registers GDBServer R trace action ignores the register mask and just
collects all registers.
It can be a problem, however with pseudo registers on some platforms if the
tdesc number doesn't match the GDB internal register number.
This is the case with ARM, the upcoming ARM tracepoint support, fails
these test cases without this patch:
gdb.trace/collection.exp: collect register locals collectively:*
GDBSever would exit with: unhandled register size
Since the register number is not mapped.
This patch fixes these issues by calling gdbarch_remote_register_number
before encoding the register number in the ax_reg or ax_reg_mask operation.
Tested on x86 native-gdbserver no regressions observed.
gdb/ChangeLog:
* ax-general.c (ax_reg): Call gdbarch_remote_register_number.
(ax_reg_mask): Likewise.
This unbreaks pending/delayed breakpoints handling, as well as
hardware watchpoints, on MIPS.
Ref: https://sourceware.org/ml/gdb-patches/2016-02/msg00681.html
The MIPS kernel reports SI_KERNEL for all kernel generated traps,
instead of TRAP_BRKPT / TRAP_HWBKPT, but GDB isn't aware of this.
Basically, this commit:
- Folds watchpoints logic into check_stopped_by_breakpoint, and
renames it to save_stop_reason.
- Adds GDB_ARCH_IS_TRAP_HWBKPT.
- Makes MIPS set both GDB_ARCH_IS_TRAP_BRPT and
GDB_ARCH_IS_TRAP_HWBKPT to SI_KERNEL. In save_stop_reason, we
handle the case of the same si_code returning true for both
TRAP_BRPT and TRAP_HWBKPT by looking at what the debug registers
say.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2016-02-24 Pedro Alves <palves@redhat.com>
* linux-nat.c (save_sigtrap) Delete.
(stop_wait_callback): Call save_stop_reason instead of
save_sigtrap.
(check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this. Bits of save_sigtrap folded here.
Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous
GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT. Factor out
common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_nat_filter_event): Call save_stop_reason instead of
save_sigtrap.
* nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT
si_code for MIPS.
* nat/linux-ptrace.h: Fix "TRAP_HWBPT" typo in x86 table. Add
comments on MIPS behavior.
(GDB_ARCH_IS_TRAP_HWBKPT): Define for all archs.
gdb/gdbserver/ChangeLog:
2016-02-24 Pedro Alves <palves@redhat.com>
* linux-low.c (check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this. Use GDB_ARCH_IS_TRAP_HWBKPT and
handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.
Factor out common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_low_filter_event): Call save_stop_reason instead of
check_stopped_by_breakpoint and check_stopped_by_watchpoint.
Update comments.
(linux_wait_1): Update comments.
