I happen to see REMOTE_EXAMPLES isn't used anywhere, so this patch
removes it.
REMOTE_EXAMPLES was added in the following commit in 1991,
commit 86bbb439c8
Author: John Gilmore <gnu@cygnus>
Date: Fri May 3 19:57:13 1991 +0000
There should be a Makefile in the cvs main directory, configured
for "./config.gdb none", so that things like "make tags" and "make tar"
will work.
and it was used like:
TARFILES = ${TAGFILES_MAINDIR} ${OTHERS} ${REMOTE_EXAMPLES}
However TARFILES was removed by the change latter in 1994,
Tue Aug 16 15:24:03 1994 Jim Kingdon (kingdon@lioth.cygnus.com)
* symtab.c (decode_line_1): If funfirstline and we get a
non-LOC_BLOCK symbol (e.g. variable or type), then error().
* Makefile.in (TARFILES, NONSRC, SFILES_STAND, SFILES_KGDB):
Remove; unused.
Since then, REMOTE_EXAMPLES is not used any more.
gdb:
2015-07-27 Yao Qi <yao.qi@linaro.org>
* Makefile.in (REMOTE_EXAMPLES): Remove it.
When using GDB to debug an RX target using the GDB remote protocol,
using a Renesas supplied debug agent, I encountered the following
assertion error:
thread.c:85: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
This assertion error occurs due to the fact that the value associated
with inferior_ptid is not on the thread list.
The remote debug output (obtained with "set debug remote 1") is fairly
short, so I will include it up to the point where things go wrong -
which is somewhat before the assertion failure:
(gdb) target remote coyote.lan:61234
Remote debugging using coyote.lan:61234
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+#c9...Ack
Packet received: PacketSize=c00;qXfer:memory-map:read-;qXfer:features:read-;QStartNoAckMode+;multiprocess+;QNonStop+
Packet qSupported (supported-packets) is supported
Sending packet: $QStartNoAckMode#b0...Ack
Packet received: OK
Sending packet: $Hgp0.0#ad...Packet received: OK
Sending packet: $QNonStop:0#8c...Packet received: OK
Sending packet: $qTStatus#49...Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Packet received: S02
Sending packet: $qfThreadInfo#bb...Packet received: m1
Sending packet: $qsThreadInfo#c8...Packet received: l
Sending packet: $qAttached:a410#bf...Packet received: 0
Packet qAttached (query-attached) is supported
Sending packet: $Hc-1#09...Packet received: OK
Sending packet: $qC#b4...Packet received: QC not supported
Above is the trace starting from the invocation of "target remote"
through the call of get_current_thread() in remote_start_remote().
Below, I've pasted this line of code along with additional lines of
context. The test following the call is especially important to
understanding both the problem and my patch.
/* We have thread information; select the thread the target
says should be current. If we're reconnecting to a
multi-threaded program, this will ideally be the thread
that last reported an event before GDB disconnected. */
inferior_ptid = get_current_thread (wait_status);
if (ptid_equal (inferior_ptid, null_ptid))
{
/* Odd... The target was able to list threads, but not
tell us which thread was current (no "thread"
register in T stop reply?). Just pick the first
thread in the thread list then. */
inferior_ptid = thread_list->ptid;
}
}
Prior to getting to the code pasted above, remote_start_remote()
made a call to target_update_thread_list(). This corresponds to the
following lines from the above trace:
Sending packet: $qfThreadInfo#bb...Packet received: m1
Sending packet: $qsThreadInfo#c8...Packet received: l
Sending packet: $qAttached:a410#bf...Packet received: 0
Packet qAttached (query-attached) is supported
Once target_update_thread_list has completed, the thread list
contains a single entry: {pid = 42000, lwp = 1, tid = 0}.
remote_start_remote() then makes a call to set_continue_thread(),
accounting for this line of the trace:
Sending packet: $Hc-1#09...Packet received: OK
Finally, the call to get_current_thread() is responsible for the last
line of the trace that I provided above:
Sending packet: $qC#b4...Packet received: QC not supported
get_current_thread() calls stop_reply_extract_thread() with the wait
status. This returns null_ptid.
get_current_thread() then calls remote_current_thread with a null
inferior_ptid. After the calls to putpkt() and getpkt(), rs->buf[0]
is 'Q', so read_ptid() is called and its result is returned.
The buffer passed to read_ptid() is " not supported". read_ptid ultimately
returns a ptid of {pid = 4200, lwp = 0, tid = 0}.
However, this thread is not on the thread list. As noted earlier, the
call to target_update_thread_list() had placed {pid = 42000, lwp = 1,
tid = 0} on the list. This is the only thread in the list.
When these calls ultimately return to remote_start_remote(),
inferior_ptid gets set to {pid = 4200, lwp = 0, tid = 0}, which
(again) is not on the thread list.
It appears to me that the string " not supported" is coming from the
debug agent. If so, it should be fixed, but I don't see a reason to
not consult the thread list in order to place a valid thread id in
inferior_ptid.
This (consultation of the thread list) is what is done when
inferior_ptid is null_ptid:
if (ptid_equal (inferior_ptid, null_ptid))
{
/* Odd... The target was able to list threads, but not
tell us which thread was current (no "thread"
register in T stop reply?). Just pick the first
thread in the thread list then. */
inferior_ptid = thread_list->ptid;
}
My patch causes a null inferior_ptid to be returned by read_ptid when
no thread id is found in the response from the debug agent. This
return value ends up being returned by remote_current_thread() and
then by get_current_thread. The assignment then places this null
value into inferior_ptid. That, in turn, allows the ptid_equal test
(noted above) to fetch a valid thread from the thread list. I no
longer see the assertion failure due a good value (which is on the
thread list) being placed in inferior_ptid.
This patch also adds two log warnings that may be output when "set
debug remote 1" is used. When running against the Renesas debug agent
mentioned earlier, this is the relevant portion of the log output:
Sending packet: $qC#b4...Packet received: QC not supported
warning: garbage in qC reply
warning: couldn't determine remote current thread; picking first in list.
gdb/ChangeLog:
* remote.c (read_ptid): Return null_ptid when no thread id
is found.
(remote_current_thread): Add log warning for malformed
qC reply.
(remote_start_remote): Add log warning when current thread
not found.
This reverts commit b558ff043d.
This reverts commit 4a11f20659.
The initial import commit failed to retain local changes made to
readline's configure.in (and the commit message erroneously stated that
there were no local changes that needed to be reapplied). Also the
import caused a couple of build errors and a scattering of testsuite
regressions throughout many arches. It's probably better to start over
with this import, hopefully more carefully next time.
Regressions, e.g.,
http://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/1501
gdb/testsuite/ChangeLog:
Revert:
* Makefile.in (check/%.exp): Pass directory for GDB_PARALLEL.
(workers/%.worker, build-perf): New rule.
(GDB_PERFTEST_MODE): New variable.
(check-perf): Use it.
(clean): Clean up gdb.perf parallel build subdirs.
* lib/build-piece.exp: New file.
* lib/cache.exp (gdb_do_cache): Include $GDB_PARALLEL in path name.
* lib/gdb.exp (standard_output_file): Include $GDB_PARALLEL in path
name.
(standard_temp_file): Ditto.
(GDB_PARALLEL handling): Make outputs,temp,cache directories as subdirs
of $GDB_PARALLEL.
This patch syncs our upstream copy of readline from version 6.2 to the
latest version, 7.0 alpha (released July 10 2015).
I essentially copied what was done the last time readline was synced,
when Jan updated to readline 6.2 in 2011:
http://sourceware.org/ml/gdb-patches/2011-05/msg00003.html
Procedure:
1. I extracted the readline-7.0-alpha tarball on top of readline/.
2. I deleted all the new files under doc/ that were deliberately omitted
before.
3. I regenerated readline/configure and readline/examples/rlfe/configure
using autoconf 2.64. No other configure files need regenerating.
4. I updated the function gdb_printable_part in completer.c with a
trivial change made to the readline function it is based off of,
printable_part in readline/complete.c. There is more work to be done in
completer.c to sync it with readline/complete.c, but it is non-trivial
and should probably be done separately anyway.
Local patches that had to be reapplied:
None. readline 7.0 alpha contains all of our local readline
patches.
New files in readline/:
colors.{c,h}
examples/{hist_erasedups,hist_purgecmd,rl-callbacktest,rlbasic}.c
parse-colors.{c,h}
readline.pc.in
configure.ac
Deleted files in readline/:
configure.in
Regressions:
After the sync there is one testsuite regression, the test
"signal SIGINT" in gdb.gdb/selftest.exp which now FAILs. Previously,
the readline 6.2 SIGINT handler would temporarily reinstall the
underlying application's SIGINT handler and immediately re-raise SIGINT
so that the orginal handler gets invoked. But now (since readline 6.3)
its SIGINT handler does not re-raise SIGINT or directly invoke the
original handler; it now sets a flag marking that SIGINT was raised, and
waits until readline explicitly has control to call the application's
SIGINT handler. Anyway, because SIGINT is no longer re-raised from
within readline's SIGINT handler, doing "signal SIGINT" with a stopped
inferior gdb process will no longer resume and then immediately stop the
process (since there is no 2nd SIGINT to immediately catch). Instead,
the inferior gdb process will now just print "Quit" and continue to run.
So with this commit, this particular test case is adjusted to reflect
this change in behavior (we now have to send a 2nd SIGINT manually to
stop it).
Aside from this one testsuite regression, I personally noticed no
regression in user-visible behavior. Though I only tested on x86_64
and on i686 Debian Stretch.
Getting this kind of change in at the start of the GDB 7.11 development
cycle will allow us to get a lot of passive testing from developers and
from bleeding-edge users.
readline/ChangeLog.gdb:
Import readline 7.0 alpha
* configure: Regenerate.
* examples/rlfe/configure: Regenerate.
gdb/ChangeLog:
* completer.c (gdb_printable_part): Sync with readline function
it is based off of.
gdb/testsuite/ChangeLog:
* gdb.gdb/selftest.exp (test_with_self): Update test to now
expect the GDB inferior to no longer immediately stop after
being resumed with "signal SIGINT".
I think I lost a patch along the way, because I remember needing
something like this, but the reverted patch isn't the right way to
do this. Removing ...
gdb/testsuite/ChangeLog:
* gdb.perf/lib/perftest/measure.py (MeasurementCpuTime::stop): Print
result.
(MeasurementWallTime::stop): Ditto.
(MeasurementVmSizeTime::stop): Ditto.
These testcases are mocks of real programs.
GDB doesn't care what the programs do, they just have to look
and/or behave like the real program.
These testcases exercise gdb when debugging really large programs.
E.g., gmonster-1 has 10,000 CUs, and gmonster-2 has 1000 shared libs
(which is actually a little small, 5000 would be more accurate).
gdb/testsuite/ChangeLog:
* gdb.perf/lib/perftest/utils.py: New file.
* gdb.perf/gm-hello.cc: New file.
* gdb.perf/gm-pervasive-typedef.cc: New file.
* gdb.perf/gm-pervasive-typedef.h: New file.
* gdb.perf/gm-std.cc: New file.
* gdb.perf/gm-std.h: New file.
* gdb.perf/gm-use-cerr.cc: New file.
* gdb.perf/gm-utils.h: New file.
* gdb.perf/gmonster-null-lookup.py: New file.
* gdb.perf/gmonster-pervasive-typedef.py: New file.
* gdb.perf/gmonster-print-cerr.py: New file.
* gdb.perf/gmonster-ptype-string.py: New file.
* gdb.perf/gmonster-runto-main.py: New file.
* gdb.perf/gmonster-select-file.py: New file.
* gdb.perf/gmonster1-null-lookup.exp: New file.
* gdb.perf/gmonster1-pervasive-typedef.exp: New file.
* gdb.perf/gmonster1-print-cerr.exp: New file.
* gdb.perf/gmonster1-ptype-string.exp: New file.
* gdb.perf/gmonster1-runto-main.exp: New file.
* gdb.perf/gmonster1-select-file.exp: New file.
* gdb.perf/gmonster1.cc: New file.
* gdb.perf/gmonster1.exp: New file.
* gdb.perf/gmonster2-null-lookup.exp: New file.
* gdb.perf/gmonster2-pervasive-typedef.exp: New file.
* gdb.perf/gmonster2-print-cerr.exp: New file.
* gdb.perf/gmonster2-ptype-string.exp: New file.
* gdb.perf/gmonster2-runto-main.exp: New file.
* gdb.perf/gmonster2-select-file.exp: New file.
* gdb.perf/gmonster2.cc: New file.
* gdb.perf/gmonster2.exp: New file.
gdb/testsuite/ChangeLog:
* gdb.perf/README: New file.
* lib/perftest.exp (tcl_string_list_to_python_list): New function.
* lib/gen-perf-test.exp: New file.
gdb/testsuite/ChangeLog:
* gdb.base/watchpoint.exp (test_complex_watchpoint): Remove
compiler_info references.
* gdb.cp/temargs.exp: Ditto.
* lib/gdb.exp: Unset compiler_info instead of setting to "unknown".
(get_compiler_info): Early exit if already computed. Set compiler_info
to "unknown" if there was a problem.
(test_compiler_info): Add function comment. Call get_compiler_info.
gdb/testsuite/ChangeLog:
* Makefile.in (check/%.exp): Pass directory for GDB_PARALLEL.
(workers/%.worker, build-perf): New rule.
(GDB_PERFTEST_MODE): New variable.
(check-perf): Use it.
(clean): Clean up gdb.perf parallel build subdirs.
* lib/build-piece.exp: New file.
* lib/cache.exp (gdb_do_cache): Include $GDB_PARALLEL in path name.
* lib/gdb.exp (standard_output_file): Include $GDB_PARALLEL in path
name.
(standard_temp_file): Ditto.
(GDB_PARALLEL handling): Make outputs,temp,cache directories as subdirs
of $GDB_PARALLEL.
The gdb_skip_xml_test procedure explicitly says that it cannot be
invoked when GDB is running. However, the testcase for "catch
syscall" is wrongly doing that, which is causing a failure on
native-extended-gdbserver tests:
new FAIL: gdb.base/catch-syscall.exp: set tdesc filename /home/gdb-buildbot/fedora-x86-64-3/fedora-x86-64-native-extended-gdbserver-m32/build/gdb/testsuite/outputs/gdb.base/catch-syscall/trivial.xml (got interactive prompt)
This obvious commit fixes this, by calling gdb_exit before gdb_skip_xml_test.
Checked in as obvious.
gdb/testsuite/ChangeLog
2015-07-24 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/catch-syscall.exp: Call gdb_exit before
gdb_skip_xml_test.
The buildbot noticed that the enum __ptrace_request series broke the
s390 GNU/Linux build:
../../binutils-gdb/gdb/s390-linux-nat.c: In function 'fetch_regs':
../../binutils-gdb/gdb/s390-linux-nat.c:226:54: error: macro "ptrace" requires 4 arguments, but only 3 given
if (ptrace (PTRACE_PEEKUSR_AREA, tid, (long) &parea) < 0)
^
../../binutils-gdb/gdb/s390-linux-nat.c: In function 'store_regs':
../../binutils-gdb/gdb/s390-linux-nat.c:243:54: error: macro "ptrace" requires 4 arguments, but only 3 given
if (ptrace (PTRACE_PEEKUSR_AREA, tid, (long) &parea) < 0)
^
Fix this the same way it's handled everywhere else -- just pass 0 as
forth argument, which also handles non-varargs ptrace prototypes in
non-glibc libcs, e.g., Bionic (if it ever gets a s390 port...).
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* s390-linux-nat.c (fetch_regs, store_regs, fetch_fpregs)
(s390_stopped_by_watchpoint, s390_prepare_to_resume): Pass 0 as
forth argument to ptrace PTRACE_PEEKUSR_AREA/PTRACE_POKEUSR_AREA.
I have patches that:
1 - make the CLI print stop info from a normal_stop observer, like MI
does.
2 - happen to change the order in which the Python and CLI/TUI
normal_stop observers are installed.
With those in place, py-events.exp regresses like shown below [1],
because the Python stop events are output before CLI prints stop info,
instead of after, and the test doesn't expect that.
With the same Python hooks, the order in which MI and Python events is
emited today is already undefined, because MI also uses the
normal_stop observer for output. I see no reason that we should in
general define the order observers, interpreters and scripting
languages get their turn at being notified of these events. So this
patch makes the test cope with Python->CLI output order too.
Tested on x86_64 Fedora 20.
gdb/testsuite/
2015-07-24 Pedro Alves <palves@redhat.com>
* gdb.python/py-events.exp: Accept output between the stop event
and the prompt.
* gdb.python/py-evsignal.exp: Likewise.
* gdb.python/py-evthreads.exp: Likewise.
[1] - The regressions in question look like:
Before said patches:
(gdb) continue
Continuing.
event type: continue
Breakpoint 2, first () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.python/py-events.c:30
30 for (i = 0; i < 2; i++)
event type: stop
event type: stop
stop reason: breakpoint
first breakpoint number: 2
breakpoint number: 2
breakpoint number: 3
all threads stopped
(gdb) PASS: gdb.python/py-events.exp: continue
After said patches:
(gdb) continue
Continuing.
event type: continue
event type: stop
event type: stop
stop reason: breakpoint
first breakpoint number: 2
breakpoint number: 2
breakpoint number: 3
all threads stopped
Breakpoint 2, first () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.python/py-events.c:30
30 for (i = 0; i < 2; i++)
(gdb) FAIL: gdb.python/py-events.exp: continue
If a non-leader thread exits the process while all other threads are
ptrace-stopped, native gdb fails an assertion. The test added by this
commit catches it:
/home/pedro/gdb/mygit/build/../src/gdb/linux-nat.c:3198: internal-error: linux_nat_filter_event: Assertion `lp->resumed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.threads/non-leader-exit-process.exp: program exits normally (GDB internal error)
The fix is just to remove the assertion.
With that out of the way, neither GDB not GDBserver handle this
perfectly though, so I'm adding a KFAIL:
(gdb) continue
Continuing.
[Thread 0x7ffff7fc0700 (LWP 15350) exited]
No unwaited-for children left.
Couldn't get registers: No such process.
(gdb) KFAIL: gdb.threads/non-ldr-exit.exp: program exits normally (PRMS: gdb/18717)
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
PR gdb/18717
* linux-nat.c (linux_nat_filter_event): Don't assert that the lwp
is resumed, and extend the debug log.
gdb/testsuite/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
PR gdb/18717
* gdb.threads/non-ldr-exit.c: New file.
* gdb.threads/non-ldr-exit.exp: New file.
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00629.html
This fixes the bogus command line in the error message shown when the
SHELL environment variable points somewhere that's not something that
resembles a shell:
$ SHELL=/nonexisting gdb /home/pedro/a.out
(gdb) r
Starting program: /home/pedro/a.out
- Cannot exec /home/pedro/a.out -c exec /home/pedro/a.out .
+ Cannot exec /nonexisting -c exec /home/pedro/a.out .
Error: No such file or directory
During startup program exited with code 127.
(gdb)
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* fork-child.c (fork_inferior): Print argv[0] instead of exec_file.
Building in C++ mode issues ~40 warnings like this:
../../src/gdb/linux-nat.c: In function ‘int linux_handle_extended_wait(lwp_info*, int, int)’:
../../src/gdb/linux-nat.c:2016:51: warning: invalid conversion from ‘int’ to ‘__ptrace_request’ [-fpermissive]
ptrace (PTRACE_GETEVENTMSG, pid, 0, &new_pid);
The issue is that in glibc, ptrace's first parameter is an enum.
That's not a problem if we pick the PTRACE_XXX requests from
sys/ptrace.h, as those will be values of the corresponding enum.
However, we have fallback definitions for PTRACE_XXX symbols when the
system headers miss them (such as PTRACE_GETEVENTMSG above), and those
are plain integer constants. E.g., nat/linux-ptrace.h:
#define PTRACE_GETEVENTMSG 0x4201
One idea would be to fix this by defining those fallbacks like:
-#define PTRACE_GETEVENTMSG 0x4201
+#define PTRACE_GETEVENTMSG ((enum __ptrace_request) 0x4201)
However, while glibc's ptrace uses enum __ptrace_request for first
parameter:
extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
other libc's, like e.g., Android's bionic do not -- in that case, the
first parameter is int:
long ptrace(int request, pid_t pid, void * addr, void * data);
So the fix I came up is to make configure/ptrace.m4 also detect the
type of the ptrace's first parameter and defin PTRACE_TYPE_ARG1, as
already does the for parameters 3-4, and then simply wrap ptrace with
a macro that casts the first argument to the detected type. (I'm
leaving adding a nicer wrapper for when we drop building in C).
While this adds the wrapper, GNU/Linux files won't use it until the
next patch, which makes all native GNU/Linux files include
gdb_ptrace.h.
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* ptrace.m4 (ptrace tests): Test in C++ mode. Try with 'enum
__ptrace_request as first parameter type instead of int.
(PTRACE_TYPE_ARG1): Define.
* nat/gdb_ptrace.h [!PTRACE_TYPE_ARG5] (ptrace): Define as wrapper
that casts first argument to PTRACE_TYPE_ARG1.
* config.in: Regenerate.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* config.in: Regenerate.
* configure: Regenerate.
Now that gdbserver's configure defines PTRACE_TYPE_ARGx etc., we'll be
able to make gdbserver use gdb_ptrace.h too. Move it to the native
target files directory.
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* gdb_ptrace.h: Move ...
* nat/gdb_ptrace.h: ... here.
* inf-ptrace.c: Adjust.
This factors the ptrace checks out of gdb's configure.ac to a new
ptrace.m4 file, and then makes gdbserver's configure.ac source it too.
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* acinclude.m4: Include ptrace.m4.
* configure.ac: Call GDB_AC_PTRACE and move ptrace checks ...
* ptrace.m4: ... to this new file.
gdb/gdbserver/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* acinclude.m4: Include ../ptrace.m4.
* configure.ac: Call GDB_AC_PTRACE.
* config.in, configure: Regenerate.
As the result of the previous patch, new_inferior is no longer used.
This patch is to remove it.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_create_inferior): Remove setting to
proc->priv->new_inferior.
(linux_attach): Likewise.
(linux_low_filter_event): Likewise.
* linux-low.h (struct process_info_private) <new_inferior>: Remove.
Nowadays, when --wrapper is used, GDBserver skips extra traps/stops
in the wrapper program, and stops at the first instruction of the
program to be debugged. However, GDBserver created target description
in the first stop of inferior, and the executable of the inferior
is the wrapper program rather than the program to be debugged. In
this way, the target description can be wrong if the architectures
of wrapper program and program to be debugged are different. This
is shown by some fails in gdb.server/wrapper.exp on buildbot.
We are testing i686-linux GDB (Fedora-i686) on an x86_64-linux box
(fedora-x86-64-4) in buildbot, such configuration causes fails in
gdb.server/wrapper.exp like this:
spawn /home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/../../gdb/gdbserver/gdbserver --once --wrapper env TEST=1 -- :2346 /home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/outputs/gdb.server/wrapper/wrapper
Process /home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/outputs/gdb.server/wrapper/wrapper created; pid = 8795
Can't debug 64-bit process with 32-bit GDBserver
Exiting
target remote localhost:2346
localhost:2346: Connection timed out.
(gdb) FAIL: gdb.server/wrapper.exp: setting breakpoint at marker
See https://sourceware.org/ml/gdb-testers/2015-q3/msg01541.html
In this case, program to be debugged ("wrapper") is 32-bit but wrapper
program ("/usr/bin/env") is 64-bit, so GDBserver gets the 64-bit
target description instead of 32-bit.
The root cause of this problem is that GDBserver creates target
description too early, and the rationale of fix could be creating
target description once the GDBserver skips extra traps and inferior
stops at the first instruction of the program we want to debug. IOW,
when GDBserver skips extra traps, the inferior's tdesc is NULL, and
mywait and its callees shouldn't use inferior's tdesc, so in this
patch, we skip code that requires register access, see changes in
linux_resume_one_lwp_throw and need_step_over_p.
In linux_low_filter_event, if target description isn't initialised and
GDBserver attached the process, we create target description immediately,
because GDBserver don't have to skip extra traps for attach, IOW, it
makes no sense to use --attach and --wrapper together. Otherwise, the
process is launched by GDBserver, we keep the status pending, and return.
After GDBserver skipped extra traps in start_inferior, we call a
target_ops hook arch_setup to initialise target description there.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_arch_setup): New function.
(linux_low_filter_event): If proc->tdesc is NULL and
proc->attached is true, call the_low_target.arch_setup.
Otherwise, keep status pending, and return.
(linux_resume_one_lwp_throw): Don't call get_pc if
thread->while_stepping isn't NULL. Don't call
get_thread_regcache if proc->tdesc is NULL.
(need_step_over_p): Return 0 if proc->tdesc is NULL.
(linux_target_ops): Install arch_setup.
* server.c (start_inferior): Call the_target->arch_setup.
* target.h (struct target_ops) <arch_setup>: New field.
(target_arch_setup): New marco.
* lynx-low.c (lynx_target_ops): Update.
* nto-low.c (nto_target_ops): Update.
* spu-low.c (spu_target_ops): Update.
* win32-low.c (win32_target_ops): Update.
Nowadays, we set proc->priv->new_inferior to 1 inside linux_add_process,
and new_inferior is used as a flag to initialise target description later.
linux_add_process is used for the three cases, fork/vfork event
(handle_extended_wait), run the program (linux_create_inferior), and
attach to the process (linux_attach). In the first case, the child's
target description is copied from parent's, so we don't need to initialise
target description again later, which means we don't need to set
proc->priv->new_inferior to 1 in this case. For the rest of two cases,
we need this flag.
This patch move the code setting proc->priv->new_inferior to 1 inside
linux_add_process to linux_create_inferior and linux_attach. No
functionality is changed.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_add_process): Don't set
proc->priv->new_inferior.
(linux_create_inferior): Set proc->priv->new_inferior to 1.
(linux_attach): Likewise.
This patch is to refactor function start_inferior that signal_pid
is return in one place.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* server.c (start_inferior): Code refactor.
My patch series will affect the code starting inferior in GDBserver
(callees of start_inferior), so we need tests to cover how
start_inferior is used in different cases.
In server.c:process_serial_event, start_inferior is used when
GBDserver receives 'R' packet, and this patch is to add a test
for this path, and see how --wrapper option works when the process
is restarted.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* gdb.server/ext-wrapper.exp: Test --wrapper option when
restarting process.
When I run gdb.server/ext-restart.exp, I get the following GDB internal
error,
run^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
Sending packet: $vKill;53c5#3d...Packet received: OK^M
Packet vKill (kill) is supported^M
Sending packet: $vFile:close:6#b6...Packet received: F0^M
Sending packet: $vFile:close:3#b3...Packet received: F0^M
Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart ^M
Sending packet: $QDisableRandomization:1#cf...Packet received: OK^M
Sending packet: $R0#82...Sending packet: $qC#b4...Packet received: QCp53c5.53c5^M <-- [1]
Sending packet: $qAttached:53c5#c9...Packet received: E01^M
warning: Remote failure reply: E01^M
....
0x00002aaaaaaac2d0 in ?? () from target:/lib64/ld-linux-x86-64.so.2^M
/home/yao/SourceCode/gnu/gdb/git/gdb/thread.c:88: internal-error: inferior_thread: Assertion `tp' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.server/ext-restart.exp: run to main (GDB internal error)
Resyncing due to internal error.
the test is to restart the program, to make sure GDBserver handles
packet 'R' correctly. From the GDBserver output, we can see,
Remote debugging from host 127.0.0.1^M
Process /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart created; pid = 21445^M
GDBserver restarting^M
Process /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart created; pid = 21446^M
Killing process(es): 21446
we first start process 21445(0x53c5), kill it and restart a new process
21446. However, in the gdb output above [1], we can see that the reply
of qC is still the old process id rather than the new one. Looks
general_thread isn't up to date after GDBserver receives R packet.
This patch is to update general_thread after call start_inferior.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* server.c (process_serial_event): Set general_thread.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* gdb.server/ext-restart.exp: New file.
We didn't test --wrapper option in extended-remote before, this patch
is to add a test case for it. In order to pass option --wrapper to
gdbserver in extended-remote, I add arg in gdbserver_start_extended,
and its default value is "", so that other places use
gdbserver_start_extended don't have to be updated.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdbserver_start_extended): Add
argument options.
* gdb.server/ext-wrapper.exp: New file.
Dummy CUs are used by the incremental linker to pre-allocate space
in the output file. They have a DWARF header but no contents.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_per_cu_data): Add comment.
(load_cu): Handle dummy CUs.
(dw2_do_instantiate_symtab, process_queuef): Ditto.
(dwarf2_fetch_die_loc_sect_off, dwarf2_fetch_constant_bytes): Ditto.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-dummy-cu.S: New file.
* gdb.dwarf2/dw2-dummy-cu.exp: New file.
The ltpy_get_all_source_lines function, use to implement
the gdb.LineTable.source_lines method, returns a list:
source_list = PyDict_Keys (source_dict);
return source_list;
This patch fixes the function's documentation as well as its docstring
to say that it returns a list rather than a FrozenSet.
gdb/ChangeLog:
* py-linetable.c (ltpy_get_all_source_lines): Adjust function
documentation to say that it returns a list rather than
a FrozenSet.
(linetable_object_methods): Update the docstring of the
"source_line" entry.
Tested on x86_64-linux.
When a dynamic array type contains a typedef-wrapped array, an assertion
failure occurs during type resolution. This is what happens in the
following Ada case:
type Rec_Type is record
I : Integer;
B : Boolean;
end record;
type Vec_Type is array (1 .. 4) of Rec_Type;
type Array_Type is array (Positive range <>) of Vec_Type;
If users try to print or even pass to an inferior call a variable A of
type Array_Type, GDB will raise an error:
(gdb) print a
../../src/gdb/gdbtypes.c:1807: internal-error:
resolve_dynamic_array: Assertion `TYPE_CODE (type) ==
TYPE_CODE_ARRAY' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
What happens is that during dynamic array type resolution, we first peel
TYPE_CODE_TYPEDEF layers wrapping the array element type and check if
its type is itself TYPE_CODE_ARRAY. If it is, we pass the
typedef-wrapped type to a recursive call to resolve_dynamic_array
whereas this function expects only TYPE_CODE_ARRAY types.
This patch makes it pass the peeled type to the recursive call so that
type resolution can continue smoothly.
gdb/ChangeLog:
* gdbtypes.c (resolve_dynamic_array): Pass the peeled element
type to the recursive call instead of the original (maybe
TYPE_CODE_TYPEDEF) type.
gdb/testsuite/ChangeLog:
* gdb.ada/var_arr_typedef.exp: New testcase.
* gdb.ada/var_arr_typedef/pack.adb: New file.
* gdb.ada/var_arr_typedef/pack.ads: New file.
* gdb.ada/var_arr_typedef/var_arr_typedef.adb: New file.
Nowadays aarch64_linux_can_use_hw_breakpoint always return one, but it
can be smarter, say, if GDB knows target doesn't support HW watchpoint
or breakpoint because HW watchpoint/breakpoint is disabled in linux
kernel, for example, it can safely return zero.
gdb:
2015-07-23 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_can_use_hw_breakpoint): If
TYPE is watchpoint, return zero if aarch64_num_wp_regs is zero.
If TYPE is breakpoint, return zero if arch64_num_bp_regs is zero.
There are also some duplication on getting HW watchpoint/breakpoint
registers info between GDB and GDBserver. This patch moves them
to nat/aarch64-linux-hw-point.c.
Note that ENABLE_NLS is not defined in GDBserver, so it should be OK
to use _( markup.
gdb:
2015-07-21 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_get_debug_reg_capacity):
Move it to nat/aarch64-linux-hw-point.c.
(aarch64_linux_child_post_startup_inferior): Update.
* nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity):
New function.
* nat/aarch64-linux-hw-point.h (aarch64_linux_get_debug_reg_capacity):
Declare it.
gdb/gdbserver:
2015-07-21 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_arch_setup): Remove code and call
aarch64_linux_get_debug_reg_capacity.
Since multi_line was moved to gdb.exp in a slightly stricter form,
The gdb.ada/info_exc.exp:info exceptions test has been failing.
This is because it now expects a new-line sequence at the end of
each argument given to multi_line, including ".*". But the intent
when writing the test was to signify "could-be-nothing-at-all".
As a result, the test fails on x86_64-linux with a runtime built as
recommended, because of that
extra new-line sequence.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Adjust "info exceptions" expected output.
This patch is to fix two ARI warnings for nat/aarch64-linux-hw-point.{c,h}.
gdb:
2015-07-20 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux-hw-point.c (aarch64_handle_unaligned_watchpoint):
Re-indent the code.
* nat/aarch64-linux-hw-point.h: Use ULONGEST rather than
"unsigned long long".
GDB already allows statically initialized variables, located in
SEC_LOAD sections, to be placed at address 0. This change allows
uninitialized variables (which are in SEC_ALLOC sections) to be placed
address 0 as well.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_locate_sections): Allow has_section_at_zero
to be set for SEC_ALLOC sections too.
When I look at test fails related to watchpoint on aarch64-linux,
I find there are some code duplicates between GDB and GDBserver.
This patch is to move some of them to a nat/aarch64-linux-hw-point.{h,c}.
The only change I do is about the dr_changed_t typedef, which was
ULONGEST in GDB and 'unsigned long long' in GDBserver. Each bit
of dr_changed_t represents a status of each HW breakpoint or
watchpoint register, and the max number of HW breakpoint or watchpoint
registers is 16, so the width of 'unsigned long long' is sufficient.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add
nat/aarch64-linux-hw-point.h.
(aarch64-linux-hw-point.o): New rule.
* nat/aarch64-linux-hw-point.h: New file.
* nat/aarch64-linux-hw-point.c: New file.
* aarch64-linux-nat.c: Include nat/aarch64-linux-hw-point.h.
(AARCH64_HBP_MAX_NUM): Move to nat/aarch64-linux-hw-point.h.
(AARCH64_HWP_MAX_NUM, AARCH64_HBP_ALIGNMENT): Likewise.
(AARCH64_HWP_ALIGNMENT): Likewise.
(AARCH64_HWP_MAX_LEN_PER_REG): Likewise.
(AARCH64_DEBUG_NUM_SLOTS, AARCH64_DEBUG_ARCH): Likewise.
(AARCH64_DEBUG_ARCH_V8, DR_MARK_ALL_CHANGED): Likewise.
(DR_MARK_N_CHANGED, DR_CLEAR_CHANGED): Likewise.
(DR_HAS_CHANGED, DR_N_HAS_CHANGE): Likewise.
(aarch64_num_bp_regs, aarch64_num_wp_regs): Likewise.
(struct aarch64_debug_reg_state): Likewise.
(struct arch_lwp_info): Likewise.
(aarch64_linux_set_debug_regs): Likewise.
(aarch64_notify_debug_reg_change): Remove static.
(aarch64_align_watchpoint): Likewise.
(DR_CONTROL_ENABLED, DR_CONTROL_LENGTH): Likewise.
(aarch64_watchpoint_length): Likewise.
(aarch64_point_encode_ctrl_reg): Likewise
(aarch64_point_is_aligned): Likewise.
(aarch64_dr_state_insert_one_point): Likewise.
(aarch64_dr_state_remove_one_point): Likewise.
(aarch64_handle_breakpoint): Likewise.
(aarch64_handle_aligned_watchpoint): Likewise.
(aarch64_handle_unaligned_watchpoint): Likewise.
(aarch64_handle_watchpoint): Likewise.
* config/aarch64/linux.mh (NAT_FILE): Add
aarch64-linux-hw-point.o.
gdb/gdbserver:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* Makefile.in (aarch64-linux-hw-point.o): New rule.
* configure.srv (srv_tgtobj): Append aarch64-linux-hw-point.o.
* linux-aarch64-low.c: Include nat/aarch64-linux-hw-point.h.
(AARCH64_HBP_MAX_NUM): Move to nat/aarch64-linux-hw-point.h.
(AARCH64_HWP_MAX_NUM, AARCH64_HBP_ALIGNMENT): Likewise.
(AARCH64_HWP_ALIGNMENT): Likewise.
(AARCH64_HWP_MAX_LEN_PER_REG): Likewise.
(AARCH64_DEBUG_NUM_SLOTS, AARCH64_DEBUG_ARCH): Likewise.
(aarch64_num_bp_regs, aarch64_num_wp_regs): Likewise.
(AARCH64_DEBUG_ARCH_V8, DR_MARK_ALL_CHANGED): Likewise.
(DR_MARK_N_CHANGED, DR_CLEAR_CHANGED): Likewise.
(DR_HAS_CHANGED, DR_N_HAS_CHANGE): Likewise.
(struct aarch64_debug_reg_state): Likewise.
(struct arch_lwp_info): Likewise.
(aarch64_align_watchpoint): Likewise.
(DR_CONTROL_ENABLED, DR_CONTROL_LENGTH): Likewise.
(aarch64_watchpoint_length): Likewise.
(aarch64_point_encode_ctrl_reg): Likewise
(aarch64_point_is_aligned): Likewise.
(aarch64_align_watchpoint): Likewise.
(aarch64_linux_set_debug_regs):
(aarch64_dr_state_insert_one_point): Likewise.
(aarch64_dr_state_remove_one_point): Likewise.
(aarch64_handle_breakpoint): Likewise.
(aarch64_handle_aligned_watchpoint): Likewise.
(aarch64_handle_unaligned_watchpoint): Likewise.
(aarch64_handle_watchpoint): Likewise.
Some functions on handling HW watchpoint in GDB and GDBserver looks the
same except the code getting debug register state from current inferior.
In GDB, we get debug register state like this:
state = aarch64_get_debug_reg_state (ptid_get_pid (inferior_ptid));
while in GDBserver, we get debug register state like this:
state = aarch64_get_debug_reg_state ();
This patch is to move two lines above out of some functions, and pass
aarch64_debug_reg_state to these functions, in this way, these functions
are the same, and can be moved to a common place.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_handle_breakpoint): Add argument
state and don't call aarch64_get_debug_reg_state. All callers
update.
(aarch64_linux_insert_hw_breakpoint): Call
aarch64_get_debug_reg_state earlier.
(aarch64_linux_remove_hw_breakpoint): Likewise.
(aarch64_handle_aligned_watchpoint): Add argument state and
don't call aarch64_get_debug_reg_state. All callers update.
(aarch64_handle_unaligned_watchpoint): Likewise.
(aarch64_handle_watchpoint): Add argument state.
(aarch64_linux_insert_watchpoint): Call aarch64_get_debug_reg_state
earlier.
(aarch64_linux_remove_watchpoint): Likewise.
gdb/gdbserver:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_handle_breakpoint): Add argument state
and don't aarch64_get_debug_reg_state. All callers update.
(aarch64_handle_aligned_watchpoint): Likewise.
(aarch64_handle_unaligned_watchpoint): Likewise.
(aarch64_handle_watchpoint): Likewise.
(aarch64_insert_point): Call aarch64_get_debug_reg_state earlier.
(aarch64_remove_point): Likewise.
Some functions in aarch64-linux-nat.c and linux-aarch64-low.c looks
the same except for the code printing debug message. In GDB, we use
fprintf_unfiltered (gdb_stdlog, ...) while in GDBserver, we use
fprintf (stderr, ...). This patch is to change them to use debug_printf
so that these functions are the same, and I can move them to a common
place in the following patch.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_show_debug_reg_state): Use
debug_printf.
(aarch64_handle_unaligned_watchpoint): Likewise.
gdb/gdbserver:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_show_debug_reg_state): Use
debug_printf.
(aarch64_handle_unaligned_watchpoint): Likewise.
This patch is to use 'enum target_hw_bp_type' instead of int for
breakpoint type, in order to make some functions in GDB and
GDBserver looks similar.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_dr_state_insert_one_point): Change
argument type's type to 'enum target_hw_bp_type'.
(aarch64_dr_state_remove_one_point): Likewise.
(aarch64_handle_breakpoint): Likewise.
(aarch64_linux_insert_hw_breakpoint): Likewise.
(aarch64_linux_remove_hw_breakpoint): Likewise.
(aarch64_handle_aligned_watchpoint): Likewise.
aarch64_linux_get_debug_reg_capacity is called by
aarch64_linux_child_post_startup_inferior, and argument ptid is created in
inf-ptrace.c:inf_ptrace_create_inferior,
/* On some targets, there must be some explicit actions taken after
the inferior has been started up. */
target_post_startup_inferior (pid_to_ptid (pid));
so in aarch64_linux_get_debug_reg_capacity, we can get pid by ptid_get_pid,
and don't need to use get_thread_id.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_get_debug_reg_capacity): Call
ptid_get_pid instead of get_thread_id.
We did a code refacotr here
https://sourceware.org/ml/gdb-patches/2013-11/msg00063.html
> (get_current_thread): New function, factored out from ...
> (add_current_inferior_and_thread): ... this. Adjust.
>
>@@ -3332,18 +3371,8 @@ add_current_inferior_and_thread (char *wait_status)
>
> inferior_ptid = null_ptid;
>
>- /* Now, if we have thread information, update inferior_ptid. First
>- if we have a stop reply handy, maybe it's a T stop reply with a
>- "thread" register we can extract the current thread from. If
>- not, ask the remote which is the current thread, with qC. The
>- former method avoids a roundtrip. Note we don't use
>- remote_parse_stop_reply as that makes use of the target
>- architecture, which we haven't yet fully determined at this
>- point. */
>- if (wait_status != NULL)
>- ptid = stop_reply_extract_thread (wait_status);
>- if (ptid_equal (ptid, null_ptid))
>- ptid = remote_current_thread (inferior_ptid);
>+ /* Now, if we have thread information, update inferior_ptid. */
>+ ptid = get_current_thread (wait_status);
but after the refactor, local variable ptid is used without
initialisation. However, before this change, ptid is initialised to
null_ptid. This error can be found by valgrind too...
==3298== at 0x6B99BA: ptid_equal (ptid.c:80)
==3298== by 0x4C67FF: get_current_thread (remote.c:3484)
==3298== by 0x4C6951: add_current_inferior_and_thread (remote.c:3511)
==3298== by 0x4C762C: extended_remote_create_inferior (remote.c:8506)
==3298== by 0x5A5312: run_command_1 (infcmd.c:606)
==3298== by 0x68B4FB: execute_command (top.c:463)
==3298== by 0x5C7214: command_handler (event-top.c:494)
==3298== by 0x5C78A3: command_line_handler (event-top.c:692)
==3298== by 0x6DEB57: rl_callback_read_char (callback.c:220)
==3298== by 0x5C7278: rl_callback_read_char_wrapper (event-top.c:171)
==3298== by 0x5C72C2: stdin_event_handler (event-top.c:432)
==3298== by 0x5C6194: gdb_wait_for_event (event-loop.c:834)
This patch initialises local variable ptid to null in get_current_thread.
We don't need to initialise ptid in add_current_inferior_and_thread,
so this patch also removes the ptid initialisation.
gdb:
2015-07-17 Yao Qi <yao.qi@linaro.org>
* remote.c (get_current_thread): Initialise ptid to null_ptid.
(add_current_inferior_and_thread): Don't initialise ptid.
This new test fails on i686 buildbot slaves,
(gdb) core-file /home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core
"/home/gdb-buildbot-2/fedora-x86-64-2/fedora-i686/build/gdb/testsuite/gdb.arch/i386-biarch-core.core"
is not a core dump: File format not recognized
(gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file
There are two problems:
(1) The testcase did not really test if elf64-i386 is supported by GDB (BFD).
That was OK for a Fedora testcase but I forgot about it when submitting it
upstream.
I haven't really verified if the GNU target is elf64-little but it seems so,
no other one seems suitable from:
elf32-x86-64
elf64-big
elf64-k1om
elf64-l1om
elf64-little
elf64-x86-64
pei-x86-64
(2) The output of the "core-file" command itself can be arbitrary as the
elf64-i386 file with x86_64 registers is really broken; but that does not
matter much, important is the following test whether core file memory is
readable.
./configure --enable-64-bit-bfd
(gdb) core-file /home/jkratoch/redhat/gdb-test-build32-plus64/gdb/testsuite/gdb.arch/i386-biarch-core.core^M
warning: Couldn't find general-purpose registers in core file.^M
Failed to read a valid object file image from memory.^M
warning: Couldn't find general-purpose registers in core file.^M
#0 <unavailable> in ?? ()^M
(gdb) FAIL: gdb.arch/i386-biarch-core.exp: core-file
x/i 0x400078^M
0x400078: hlt ^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: .text is readable
I do not know much dejagnu but I expect 'istarget' tests against the site.exp
'target_triplet' content which is set to the primary GDB target
(--target=...).
GDB is normally never configured for primary target elf64-i386, I think BFD
does not know such explicit target, it gets recognized as elf64-little.
In fact many testfiles of the GDB testsuite are wrong as they require
'istarget' (therefore primary GDB target) even for just loading arch specific
files which would be sufficient with secondary target (--enable-targets=...)
support.
This my new patch removes this 'istarget' check as it is IMO unrelated to what
we need to test. Although you are right we do 'x/i' and test for 'hlt' so
I think we should test also for available 'set architecture i386'.
We could also test by 'x/bx' instead of 'x/i' to avoid such additional
test/requirement.
This testcase comes from a different bug from 2009:
https://bugzilla.redhat.com/show_bug.cgi?id=457187http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=94cd124608bf0dd359cb48a710800d72c21b30c3
That bug has been fixed in the meantime but the same testcase was reproducing
this new different bug - internal error regression - so I submitted it.
We can remove the "x/bx $address" test but it was useful for the previous bug
from 2009 as that time the internal error regression did not happen, just the
core file was not recognized (which would not be detected by the proposed
ignoring of the "core-file" command output) and so the core file was not
available. That can be tested by the "x/bx $address" test.
gdb/testsuite/ChangeLog
2015-07-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-biarch-core.exp: Replace istarget
by "complete set gnutarget". Remove expectation for the "core-file"
command.
I noticed two failure in gdb.trace/mi-trace-frame-collected.exp:
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)
In these cases, we are not collecting registers so the MI command
-trace-frame-collected should only give us the value of the PC.
However, it also gives us all of the single precision pseudo registers,
initialized with 0x0.
We can reproduce this error by simply issuing the
'maint print cooked-register' when no inferior is connected:
~~~
...
(gdb) maint print cooked-register
Name Nr Rel Offset Size Type Cooked value
x0 0 0 0 8 long <unavailable>
x1 1 1 8 8 long <unavailable>
...
d30 130 62 1540 8 *1 <unavailable>
d31 131 63 1548 8 *1 <unavailable>
s0 132 64 1556 4 *1 0x00000000
s1 133 65 1560 4 *1 0x00000000
s2 134 66 1564 4 *1 0x00000000
...
s28 160 92 1668 4 *1 0x00000000
s29 161 93 1672 4 *1 0x00000000
s30 162 94 1676 4 *1 0x00000000
s31 163 95 1680 4 *1 0x00000000
h0 164 96 1684 2 *1 <unavailable>
h1 165 97 1686 2 *1 <unavailable>
h2 166 98 1688 2 *1 <unavailable>
...
~~~
It turns out GDB does not check if S registers are valid before returning
a value for them. It should return <unavailable> in this case.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_pseudo_read_value): Mark S register as
unavailable if invalid.
