Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is now able to correctly print the entire array, but not one
element of the array. Eg:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
(gdb) p foo.three_ptr.all(1)
Cannot access memory at address 0xfffffffff4123a0c
The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.
This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
Adjust function implementation and documentation accordingly.
(ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
Update call to ada_value_ptr_subscript.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
Consider the following declaration:
type Array_Type is array (Natural range <>) of Integer;
type Array_Ptr is access all Array_Type;
for Array_Ptr'Size use 64;
Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);
This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is currently printing the value of the array incorrectly:
(gdb) p foo.three_ptr.all
$1 = (26629472 => 1, 2,
value.c:819: internal-error: value_contents_bits_eq: [...]
The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.
The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.
After fixing this issue, the debugger now correctly prints:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use VAL's enclosing type
instead of VAL's type.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
Similarly to the previous changes to gdb.reverse/sigall-reverse.exp and
gdb.reverse/until-precsave.exp this corrects the timeout tweak in
gdb.base/watchpoint-solib.exp.
This test case executes a large amount of code with a software watchpoint
enabled. This means single-stepping all the way through and takes a lot
of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 714
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 1275
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 115
(values in seconds) -- all of which having the default timeout of 60s,
set based on the requirement of the remaining test cases (other than
gdb.reverse ones).
Here again the timeout extension to have a meaning should be calculated
by scaling rather than using an arbitrary constant, and a larger factor
of 30 will do, leaving some margin. Hopefully for everyone or otherwise
we'll probably have to come up with a smarter solution.
OTOH the other test cases in this script do not require the extension so
they can be moved outside its umbrella so as to avoid unnecessary delays
if something goes wrong and a genuine timeout triggers.
* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
of 30 rather than hardcoding 120 for a slow test case. Take the
`gdb,timeout' target setting into account for this calculation.
Don't extend the timeout for the test cases that don't need it.
There are three cases in two scripts in the gdb.reverse subset that
take a particularly long time. Two of them are already attempted to
take care of by extending the timeout from the default. The remaining
one has no precautions taken. The timeout extension is ineffective
though, it is done by adding a constant rather than by scaling and as
a result while it may work for target boards that get satisfied with
the detault test timeout of 10s, it does not serve its purpose for
slower ones.
Here are indicative samples of execution times (in seconds) observed
for these cases respectively, for an ARMv7 Panda board running Linux
and a `-march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 385
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4440
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 965
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 465
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4191
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 669
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 45
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 433
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 104
Based on the performance of other tests these two test configurations
have their default timeout set to 450s and 60s respectively.
The remaining two multilibs (`-mthumb -march=armv4t' and `-mthumb
-march=armv7-a') do not produce test results usable enough to have data
available for these cases.
Based on these results I have tweaked timeouts for these cases as
follows. This, together with a suitable board timeout setting, removes
timeouts for these cases. Note that for the default timeout of 10s the
new setting for the first case in gdb.reverse/until-precsave.exp is
compatible with the old one, just a bit higher to keep the convention
of longer timeouts to remain multiples of 30s. The second case there
does not need such a high setting so I have lowered it a bit to avoid
an unnecessary delay where this test case genuinely times out.
* gdb.reverse/sigall-reverse.exp: Increase the timeout by
a factor of 2 for a slow test case. Take the `gdb,timeout'
target setting into account for this calculation.
* gdb.reverse/until-precsave.exp: Increase the timeout by
a factor of 15 and 3 respectively rather than adding 120
for a pair of slow test cases. Take the `gdb,timeout'
target setting into account for this calculation.
The recent change to introduce `gdb_reverse_timeout' turned out
ineffective for board setups that set the `gdb,timeout' target variable.
A lower `gdb,timeout' setting takes precedence and defeats the effect of
`gdb_reverse_timeout'. This is because the global timeout is overridden
in gdb_test_multiple and then again in gdb_expect.
Three timeout variables are taken into account in these two places, in
this precedence:
1. The `gdb,timeout' target variable.
2. The caller's local `timeout' variable (upvar timeout)
3. The global `timeout' variable.
This precedence is obeyed by gdb_test_multiple strictly. OTOH
gdb_expect will select the higher of the two formers and will only take
the latter into account if none of the formers is present. However the
two timeout selections are conceptually the same and gdb_test_multiple
does its only for the purpose of passing it down to gdb_expect.
Therefore I decided there is no point to keep carrying on this
duplication and removed the sequence from gdb_test_multiple, however
retaining the `upvar timeout' variable definition. This way gdb_expect
will still access gdb_test_multiple's caller `timeout' variable (if any)
via its own `upvar timeout' reference.
Now as to the sequence in gdb_expect. In addition to the three
variables described above it also takes a timeout argument into account,
as the fourth value to choose from. It is currently used if it is
higher than the timeout selected from the variables as described above.
With the timeout selection code from gdb_test_multiple gone, gone is
also the most prominent use of this timeout argument, it's now used in
a couple of places only, mostly within this test framework library code
itself for preparatory commands or suchlike. With this being the case
this timeout selection code can be simplified as follows:
1. Among the three timeout variables, the highest is always chosen.
This is so that a test case doesn't inadvertently lower a high value
timeout needed by slow target boards. This is what all test cases
use.
2. Any timeout argument takes precedence. This is for special cases
such as within the framework library code, e.g. it doesn't make sense
to send `set height 0' with a timeout of 7200 seconds. This is a
local command that does not interact with the target and setting a
high timeout here only risks a test suite run taking ages if it goes
astray for some reason.
3. The fallback timeout of 60s remains.
* lib/gdb.exp (gdb_test_multiple): Remove code to select the
timeout, don't pass one down to gdb_expect.
(gdb_expect): Rework timeout selection.
As it happens we have a board that fails a gdb.base/gcore-relro.exp
test case reproducibly and moreover the case appears to trigger a
kernel bug making the it less than usable. Specifically the board
remains responsive to some extent, however processes do not appear
to be able to successfully complete termination anymore and perhaps
more importantly further gdbserver processes can be started, but they
never reach the stage of listening on the RSP socket.
This change handles timeouts in gdbserver start properly, by throwing
a TCL error exception when gdbserver does not report listening on the
RSP socket in time. This is then caught at the outer level and
reported, and 2 rather than 1 is returned so that the caller may tell
the failure to start gdbserver and other issues apart and act
accordingly (or do nothing).
I thought letting the exception unwind further on might be a good idea
for any test harnesses out there to break outright where a gdbserver
start error is silently ignored right now, however I figured out the
calls to gdbserver-support.exp are buried down too deep in the GDB test
suite for such a change to be made easily. I think returning a distinct
return value is good enough (the API says "non-zero", so 2 is as good as
1) and we can always make the error harder in a later step if required.
With config/gdbserver.exp being used this change remains transparent
to the target board, the return value is passed up by gdb_reload and
the error exception unwinds through gdbserver_gdb_load and is caught
and handled by mi_gdb_target_load. A call to perror is still made,
reporting the timeout, and in the case of mi_gdb_target_load the
procedure returns a value denoting unsuccessful completion. An
unsuccessful completion of gdb_reload is already handled elsewhere.
An alternative gdbserver board configuration can interpret the return
value in its gdb_reload implementation and catch the error in
gdbserver_gdb_load in an attempt to recover a target board that has
gone astray, for example by rebooting the board somehow. This has
proved effective with our failing board, that now completes the
remaining test cases with no further hiccups.
* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.
Gdbserver support code uses the global timeout value to determine when
to stop waiting for a gdbserver process being started to respond before
continuing anyway. This timeout is usually as low as 10s and may not
be enough in this context, for example on the first run where the
filesystem cache is cold, even if it is elsewhere.
E.g. I observe this reliably with gdbserver started the first time in
QEMU running in the system emulation mode:
(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main
-- notice how the test harness proceeded with the `target remote ...'
command even though gdbserver hasn't completed its startup yet. A
while later when it's finally ready it's too late already. I checked
the timing here and it takes gdbserver roughly 25 seconds to start in
this scenario. Subsequent gdbserver starts in the same test run take
less time and usually complete within 10 seconds although occasionally
`target remote ...' precedes the corresponding `Listening on port...'
message again.
Therefore I have fixed this problem by setting an explicit timeout to
120s on the expect call in question. If this turns out too arbitrary
sometime, then perhaps a separate `gdbserver_timeout' setting might be
due.
* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.
Hi,
I see the following fail on arm-none-eabi target,
-var-evaluate-expression -f nat foo^M
^done,value="0x3 <_ftext+2>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: eval variable -f nat foo
the "<_ftext+2>" isn't expected in the test, so "set print symbol off"
can prevent printing it. It is obvious and I'll commit it in three
days if no comments.
gdb/testsuite:
2014-09-09 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-display.exp: Set print symbol off.
have empty bodies.
User-defined commands that have empty bodies weren't being shown because
the print function returned too soon. Now, it prints the command's name
before checking if it has any body at all. This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.
gdb/Changelog:
* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.
gdb/testsuite/Changelog:
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
https://bugzilla.redhat.com/show_bug.cgi?id=1126177
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
#0 0x992bee in value_type .../gdb/value.c:925
#1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
#2 0x87cfae in enumerate_args python/py-framefilter.c:596
#3 0x87e0b0 in py_print_args python/py-framefilter.c:968
It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.
Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.
It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.
gdb/ChangeLog
PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.
gdb/testsuite/ChangeLog
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
This patch is a fix to PR gdb/17235. The bug is about an unused
variable that got declared and set during one of the parsing phases of
an SDT probe's argument. I took the opportunity to rewrite some of the
code to improve the parsing. The bug was actually a thinko, because
what I wanted to do in the code was to discard the number on the string
being parsed.
During this portion, the code identifies that it is dealing with an
expression that begins with a sign ('+', '-' or '~'). This means that
the expression could be:
- a numeric literal (e.g., '+5')
- a register displacement (e.g., '-4(%rsp)')
- a subexpression (e.g., '-(2*3)')
So, after saving the sign and moving forward 1 char, now the code needs
to know if there is a digit followed by a register displacement prefix
operand (e.g., '(' on x86_64). If yes, then it is a register
operation. If not, then it will be handled recursively, and the code
will later apply the requested operation on the result (either a '+', a
'-' or a '~').
With the bug, the code was correctly discarding the digit (though using
strtol unnecessarily), but it wasn't properly dealing with
subexpressions when the register indirection prefix was '(', like on
x86_64. This patch also fixes this bug, and includes a testcase. It
passes on x86_64 Fedora 20.
This commit fixes the PR mentioned in $subject. It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.
This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario. I am sending
a testcase which triggers this error as well.
gdb/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* f-valprint.c (f_val_print): Specify the correct print option to
use when printing integer values.
gdb/testsuite/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.
The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.
gdb/ChangeLog:
2014-08-29 Sasha Smundak <asmundak@google.com>
* python/py-frame.c (frapy_read_register): New function.
gdb/doc/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* python.texi (Frames in Python): Add read_register description.
gdb/testsuite/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386". All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386". This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".
This commit only renames OS-independent files. The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.
gdb/ChangeLog:
* i386-nat.h: Renamed as...
* x86-nat.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
gdb/gdbserver/ChangeLog:
* i386-low.h: Renamed as...
* x86-low.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
clang was using eax to construct %0 here:
asm ("mov %%eax, 0(%0)\n\t"
"mov %%ebx, 4(%0)\n\t"
"mov %%ecx, 8(%0)\n\t"
"mov %%edx, 12(%0)\n\t"
"mov %%esi, 16(%0)\n\t"
"mov %%edi, 20(%0)\n\t"
: /* no output operands */
: "r" (data)
: "eax", "ebx", "ecx", "edx", "esi", "edi");
which caused amd64-word.exp (and others similarly) to fail.
It's a perfectly legit thing for clang to do given the available data.
The patch fixes this by marking the registers as live from the
time of the preceding breakpoint.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-pseudo.c (main): Rewrite to better specify when
eax,etc. are live with values set by gdb and thus the compiler can't
use them.
* gdb.arch/i386-pseudo.c (main): Ditto.
I see the following fails on arm-none-eabi target,
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.python/py-value.exp: print sn
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.guile/scm-value.exp: print sn
as <_ftext> is unexpected. This patch is to set print symbol off to
avoid printing this.
gdb/testsuite:
2014-08-24 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-value.exp (test_lazy_strings): Set print
symbol off.
* gdb.python/py-value.exp (test_lazy_strings): Likewise.
See the description here:
https://sourceware.org/ml/gdb-patches/2014-08/msg00283.html
This patch keeps track of whether the current line has seen a
non-zero discriminator, and if so coalesces consecutive entries
for the same line (by ignoring all entries after the first).
gdb/ChangeLog:
PR 17276
* dwarf2read.c (dwarf_record_line_p): New function.
(dwarf_decode_lines_1): Ignore subsequent line number entries
for the same line if any entry had a non-zero discriminator.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-single-line-discriminators.S: New file.
* gdb.dwarf2/dw2-single-line-discriminators.c: New file.
* gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
Some gdb.python/*.exp tests fail because the .py files aren't copied
to the (remote) host. This patch is to copy needed .py files to host.
Most of gdb.python/*.exp tests do this.
As it is still controversial to delete *.py files on host, we don't do
that in this patch.
gdb/testsuite:
2014-08-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
Program received signal SIGABRT, Aborted.
[...]
(gdb) gcore foobar
Couldn't get registers: No such process.
(gdb) info threads
[...]
(gdb) gcore foobar
Saved corefile foobar
(gdb)
gcore tries to access the exited thread:
[Thread 0x7ffff7fce700 (LWP 6895) exited]
ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process)
Without the TRY_CATCH protection testsuite FAILs for:
gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test
Cannot find new threads: debugger service failed
(gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
+
core .../gdb/testsuite/gdb.threads/gcore-thread0.test
".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)
Maybe the TRY_CATCH could be more inside update_thread_list().
Similar update_thread_list() call is IMO missing in procfs_make_note_section()
but I do not have where to verify that change.
gdb/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* linux-tdep.c (linux_corefile_thread_callback): Ignore THREAD_EXITED.
(linux_make_corefile_notes): call update_thread_list, protected against
exceptions.
gdb/testsuite/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/gcore-stale-thread.c: New file.
* gdb.threads/gcore-stale-thread.exp: New file.
Checking whether the gcore command is included in the GDB build as
proxy for checking whether core dumping is supported by the target is
useless, as gcore.o has been in COMMON_OBS since git 9b4eba8e:
2009-10-26 Michael Snyder <msnyder@vmware.com>
Hui Zhu <teawater@gmail.com>
* Makefile.in (SFILES): Add gcore.c.
(COMMON_OBS): Add gcore.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Delete gcore.o.
* config/alpha/fbsd.mh (NATDEPFILES): Ditto.
...
IOW, the command is always included in the build.
Instead, nowadays, tests bail out if actually trying to generate a
core fails with an indication the target doesn't support it. See
gdb_gcore_cmd and callers.
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
* gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test.
* gdb.base/gcore-relro-pie.exp: Likewise.
* gdb.base/gcore-relro.exp: Likewise.
* gdb.base/gcore.exp: Likewise.
* gdb.base/print-symbol-loading.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
This integrates Jan Kratochvil's nice race reproducer from PR
testsuite/12649 into the testsuite infrustructure directly.
With this, one only has to do either 'make check-read1' or 'make check
READ1="1"' to preload the read1.so library into expect.
Currently only enabled for glibc/GNU systems, and if
build==host==target.
gdb/testsuite/ChangeLog:
* Makefile.in (EXTRA_RULES, CC): New variables, get from
configure.
(EXPECT): Handle READ1 being set.
(all): Depend on EXTRA_RULES.
(check-read1, expect-read1, read1.so, read1): New rules.
* README (Testsuite Parameters): Document the READ1 make variable.
(Race detection): New section.
* configure: Regenerate.
* configure.ac: If build==host==target, and running under a
GNU/glibc system, add read1 to the extra Makefile rules.
(EXTRA_RULES): AC_SUBST it.
* lib/read1.c: New file.
gdb/ChangeLog:
* Makefile.in (check-read1): New rule.
Consider an array described in the debugging information as being
a typedef of an array type for which there is a DW_AT_data_location
attribute. Trying to print the value of that array currently yields
incorrect element values. For instance:
(gdb) print foo.three_tdef
$1 = (6293760, 0, 6293772)
The problem occurs because we check for the data_location attribute
only on the typedef type, whereas we should be checking for the
typedef's target type. As a result, GDB erroneously thinks that
there is no data_location, and therefore starts reading the array's
content from the address of the descriptor instead of the data_location
address.
gdb/ChangeLog:
* value.c (value_from_contents_and_address): Strip resolved_type's
typedef layers before checking its TYPE_DATA_LOCATION.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Add additional tests exercising
the handling of variables declared as a typedef to an array
which a DW_AT_data_location attribute.
This fixes PR symtab/14604, PR symtab/14605, and Jan's test at
https://sourceware.org/ml/gdb-patches/2014-07/msg00158.html, in a tree
with bddbbed reverted:
2014-07-22 Pedro Alves <palves@redhat.com>
* value.c (allocate_optimized_out_value): Don't mark value as
non-lazy.
The PRs are about variables described by the DWARF as being split over
multiple registers using DWARF piece information, but some of those
registers being marked as optimised out (not saved) by a later frame.
GDB currently incorrectly mishandles these partially-optimized-out
values.
Even though we can usually tell from the debug info whether a local or
global is optimized out, handling the case of a local living in a
register that was not saved in a frame requires fetching the variable.
GDB also needs to fetch a value to tell whether parts of it are
"<unavailable>". Given this, it's not worth it to try to avoid
fetching lazy optimized-out values based on debug info alone.
So this patch makes GDB track which chunks of a value's contents are
optimized out like it tracks <unavailable> contents. That is, it
makes value->optimized_out be a bit range vector instead of a boolean,
and removes the struct lval_funcs check_validity and check_any_valid
hooks.
Unlike Andrew's series which this is based on (at
https://sourceware.org/ml/gdb-patches/2013-08/msg00300.html, note some
pieces have gone in since), this doesn't merge optimized out and
unavailable contents validity/availability behind a single interface,
nor does it merge the bit range vectors themselves (at least yet).
While it may be desirable to have a single entry point that returns
existence of contents irrespective of what may make them
invalid/unavailable, several places want to treat optimized out /
unavailable / etc. differently, so each spot that potentially could
use it will need to be careful considered on case-by-case basis, and
best done as a separate change.
This fixes Jan's test, because value_available_contents_eq wasn't
considering optimized out value contents. It does now, and because of
that it's been renamed to value_contents_eq.
A new intro comment is added to value.h describing "<optimized out>",
"<not saved>" and "<unavailable>" values.
gdb/
PR symtab/14604
PR symtab/14605
* ada-lang.c (coerce_unspec_val_to_type): Use
value_contents_copy_raw.
* ada-valprint.c (val_print_packed_array_elements): Adjust.
* c-valprint.c (c_val_print): Use value_bits_any_optimized_out.
* cp-valprint.c (cp_print_value_fields): Let the common printing
code handle optimized out values.
(cp_print_value_fields_rtti): Use value_bits_any_optimized_out.
* d-valprint.c (dynamic_array_type): Use
value_bits_any_optimized_out.
* dwarf2loc.c (entry_data_value_funcs): Remove check_validity and
check_any_valid fields.
(check_pieced_value_bits): Delete and inline ...
(check_pieced_synthetic_pointer): ... here.
(check_pieced_value_validity): Delete.
(check_pieced_value_invalid): Delete.
(pieced_value_funcs): Remove check_validity and check_any_valid
fields.
(read_pieced_value): Use mark_value_bits_optimized_out.
(write_pieced_value): Switch to use
mark_value_bytes_optimized_out.
(dwarf2_evaluate_loc_desc_full): Copy the value contents instead
of assuming the whole value is optimized out.
* findvar.c (read_frame_register_value): Remove special handling
of optimized out registers.
(value_from_register): Use mark_value_bytes_optimized_out.
* frame-unwind.c (frame_unwind_got_optimized): Use
mark_value_bytes_optimized_out.
* jv-valprint.c (java_value_print): Adjust.
(java_print_value_fields): Let the common printing code handle
optimized out values.
* mips-tdep.c (mips_print_register): Remove special handling of
optimized out registers.
* opencl-lang.c (lval_func_check_validity): Delete.
(lval_func_check_any_valid): Delete.
(opencl_value_funcs): Remove check_validity and check_any_valid
fields.
* p-valprint.c (pascal_object_print_value_fields): Let the common
printing code handle optimized out values.
* stack.c (read_frame_arg): Remove special handling of optimized
out values. Fetch both VAL and ENTRYVAL before comparing
contents. Adjust to value_available_contents_eq rename.
* valprint.c (valprint_check_validity)
(val_print_scalar_formatted): Use value_bits_any_optimized_out.
(val_print_array_elements): Adjust.
* value.c (struct value) <optimized_out>: Now a VEC(range_s).
(value_bits_any_optimized_out): New function.
(value_entirely_covered_by_range_vector): New function, factored
out from value_entirely_unavailable.
(value_entirely_unavailable): Reimplement.
(value_entirely_optimized_out): New function.
(insert_into_bit_range_vector): New function, factored out from
mark_value_bits_unavailable.
(mark_value_bits_unavailable): Reimplement.
(struct ranges_and_idx): New struct.
(find_first_range_overlap_and_match): New function, factored out
from value_available_contents_bits_eq.
(value_available_contents_bits_eq): Rename to ...
(value_contents_bits_eq): ... this. Check both unavailable
contents and optimized out contents.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this.
(allocate_value_lazy): Remove reference to the old optimized_out
boolean.
(allocate_optimized_out_value): Use
mark_value_bytes_optimized_out.
(require_not_optimized_out): Adjust to check whether the
optimized_out vec is empty.
(ranges_copy_adjusted): New function, factored out from
value_contents_copy_raw.
(value_contents_copy_raw): Also copy the optimized out ranges.
Assert the destination ranges aren't optimized out.
(value_contents_copy): Update comment, remove call to
require_not_optimized_out.
(value_contents_equal): Adjust to check whether the optimized_out
vec is empty.
(set_value_optimized_out, value_optimized_out_const): Delete.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New functions.
(value_entirely_optimized_out, value_bits_valid): Delete.
(value_copy): Take a VEC copy of the 'optimized_out' field.
(value_primitive_field): Remove special handling of optimized out.
(value_fetch_lazy): Assert that lazy values have no unavailable
regions. Use value_bits_any_optimized_out. Remove some special
handling for optimized out values.
* value.h: Add intro comment about <optimized out> and
<unavailable>.
(struct lval_funcs): Remove check_validity and check_any_valid
fields.
(set_value_optimized_out, value_optimized_out_const): Remove.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New declarations.
(value_bits_any_optimized_out): New declaration.
(value_bits_valid): Delete declaration.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this, and extend comments.
gdb/testsuite/
PR symtab/14604
PR symtab/14605
* gdb.dwarf2/dw2-op-out-param.exp: Remove kfail branches and use
gdb_test.
This comment is no longer true for watchpoints since commit 31e77af2
(PR breakpoints/7143 - Watchpoint does not trigger when first set).
gdb/testsuite/
* gdb.base/watchpoint-hw-hit-once.c (main): Update comment.
In gdb.base/watchpoint-hw-hit-once.exp, test scans source and set
breakpoint on the line having "break-at-exit",
gdb_breakpoint [gdb_get_line_number "break-at-exit"]
However, in watchpoint-hw-hit-once.c, there are two lines having
this key word:
dummy = 1; /* Stub to catch break-at-exit after WATCHEE has been hit. */
dummy = 2; /* break-at-exit */
so the test sets breakpoint on the first one, while I think it is
expected to set breakpoint on the second one, as far as I can tell
from the comments in watchpoint-hw-hit-once.c:
/* Stub lines are present as no breakpoints/watchpoint gets hit if current PC
already stays on the line PC while entering "step"/"continue". */
This patch is to change the source matching pattern so that test
can correctly set breakpoint on the right line. This patch fixes
a fail we found on arm-none-eabi target.
(gdb) PASS: gdb.base/watchpoint-hw-hit-once.exp: continue
continue^M
Continuing.^M
^M
*** EXIT code 0^M
[Inferior 1 (Remote target) exited normally]^M
(gdb) FAIL: gdb.base/watchpoint-hw-hit-once.exp: continue to break-at-exit (the program exited)
Run it again on x86_64-linux, no result changes.
gdb/testsuite:
2014-08-19 Yao Qi <yao@codesourcery.com>
* gdb.base/watchpoint-hw-hit-once.exp: Set breakpoint on the
right line.
The testcase generates an assembly file where a second DW_AT_upper_bound
attribute gets generated in the array range. This was definitely
unintentional, and I only noticed this after pushing the testcase,
when dumping one more time the DWARF data using readelf.
This patch fixes it.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound
attribute in array range.
This testcase allows us to test the proper processing of both
DW_AT_data_location and DW_OP_push_object_address using a hand-crafted
testcase duplicating how we expect the Ada compiler to represent
unbounded arrays.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
This is a fix for PR c++/17132.
If this new argument is set to EVAL_AVOID_SIDE_EFFECTS, then the object's
memory will not be read while picking the best overload match.
gdb/
* eval.c: Update all calls to find_overload_match.
* valarith.c: Likewise.
(value_user_defined_cpp_op, value_user_defined_op): New
argument NOSIDE. Update all callers.
* valops.c (find_overload_match): New argument NOSIDE.
* value.h (find_overload_match): Update signature.
gdb/testsuite
* gdb.cp/pr17132.cc: New file.
* gdb.cp/pr17132.exp: New file.
gdb/
* python/lib/gdb/command/xmethods.py (set_xm_status1): Use the
'items' methods instead of 'iteritems' method on dictionaries.
gdb/testsuite/
* gdb.python/py-xmethods.py (A_getarrayind)
(E_method_char_worker.__call__, E_method_int_worker.__call__):
Use 'print' with function call syntax.
(E_method_matcher.match): Fix tab vs space indentation mixup.
I added proc generate_tracefile in this patch
https://sourceware.org/ml/gdb-patches/2014-03/msg00591.html but
tfile.exp isn't skipped as changelog entry said:
* gdb.trace/tfile.exp: Skip the test if generate_tracefile
return 0.
it is a mistake I made at the last minute. Patch below fixed it.
gdb/testsuite:
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Return -1 if generate_tracefile returns
false.
GDB in default prints the symbol associated on an address, and tests
assume that there is no symbol on address zero. However, on bare
metal target, address may be mapped to zero and there may be a
symbol. Then, some tests fail as below:
print const_cast<void *> (0)^M
$8 = (void *) 0x0 <_ftext>^M
(gdb) FAIL: gdb.cp/casts.exp: const_cast of 0
p acp->c1^M
$9 = (A *) 0x0 <_ftext>^M
(gdb) FAIL: gdb.cp/class2.exp: p acp->c1
This patch is to set print symbol off in these tests, like what
I did previously https://sourceware.org/ml/gdb-patches/2014-07/msg00257.html
gdb/testsuite:
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.cp/casts.exp: Set print symbol off.
* gdb.cp/class2.exp: Likewise.
* gdb.cp/overload.exp: Likewise.
* gdb.cp/templates.exp: Likewise.
* solib.c (solib_read_symbols): Delete "Loaded symbols for ..."
message, it is redundant with "Reading symbols from ..." message.
testsuite/
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
(test_load_shlib): Update.
I find some gdb.python tests fail on arm-none-eabi target, because the
tests assume that memory on address 0x is inaccessible. Some tests
(in gdb.base) are aware of this, so do a "x 0" check first. However,
the code is copy-n-paste.
This patch is to move the "x 0" check to a procedure in lib/gdb.exp,
and get needed tests call it. The original code matches pattern
"0x0:\[ \t\]*Error accessing memory address 0x0\r\n$gdb_prompt $", but
I remove it from the new proc is_address_zero_readable, because GDB
doesn't emit such message any more.
gdb/testsuite:
2014-08-09 Yao Qi <yao@codesourcery.com>
* gdb.base/display.exp: Invoke is_address_zero_readable.
* gdb.guile/scm-value.exp (test_value_in_inferior): Likewise.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* gdb.base/hbreak-unmapped.exp: Return if
is_address_zero_readable returns true.
* gdb.base/signest.exp: Likewise.
* gdb.base/signull.exp: Likewise.
* gdb.base/sigbpt.exp: Likewise.
* gdb.guile/scm-disasm.exp: Do the test if
is_address_zero_readable returns false.
* gdb.guile/scm-pretty-print.exp (run_lang_tests): Likewise.
* gdb.python/py-arch.exp: Likewise.
* gdb.python/py-prettyprint.exp (run_lang_tests): Likewise.
* lib/gdb.exp (is_address_zero_readable): New proc.
When I fix a bug in gdb.mi/mi-var-display.exp, I find its test
messages aren't unique, which makes some confusions for me.
$ cat testsuite/gdb.sum | grep "PASS" | sort | uniq -c | sort -n
...
2 PASS: gdb.mi/mi-var-display.exp: set format variable bar
2 PASS: gdb.mi/mi-var-display.exp: set format variable foo
2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr
2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr
2 PASS: gdb.mi/mi-var-display.exp: show format variable foo
3 PASS: gdb.mi/mi-var-display.exp: eval variable foo
This patch is to make test messages in mi-var-display.exp unique.
gdb/testsuite:
2014-08-09 Yao Qi <yao@codesourcery.com>
PR testsuite/13443
* gdb.mi/mi-var-display.exp: Make test messages unique.
Right now, "set debug target" acts a bit strangely.
Most target APIs only notice that it has changed when the target stack
is changed in some way. This is because many methods implement the
setting using the special debug target. However, a few spots do
change their behavior immediately -- any place explicitly checking
"targetdebug".
Some of this peculiar behavior is documented. However, I think that
it just isn't very useful for it to work this way. So, this patch
changes "set debug target" to take effect immediately in all cases.
This is done by simply calling update_current_target when the setting
is changed.
This required one small change in the test suite. Here a test was
expecting the current behavior.
Built and regtested on x86-64 Fedora 20.
2014-08-04 Tom Tromey <tromey@redhat.com>
* target.c (set_targetdebug): New function.
(initialize_targets): Pass set_targetdebug when creating "set
debug target".
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Debugging Output): Update for change to "set debug
target".
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Expect output from "set debug
target 0".
This fixes a test suite regession that Yao noticed.
This test checks for some specific "target debug" output
that has changed since the test was written.
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Match "to_resume", not
"target_resume".
In Ada, variable-sized field can be located at any position of
a structure. Consider for instance the following declarations:
Dyn_Size : Integer := 1;
type Table is array (Positive range <>) of Integer;
type Inner is record
T1 : Table (1 .. Dyn_Size) := (others => 1);
T2 : Table (1 .. Dyn_Size) := (others => 2);
end record;
type Inner_Array is array (1 .. 2) of Inner;
type Outer is
record
I0 : Integer := 0;
A1 : Inner_Array;
Marker : Integer := 16#01020304#;
end record;
Rt : Outer;
What this does is declare a variable "Rt" of type Outer, which
contains 3 fields where the second (A1) is of type Inner_Array.
type Inner_Array is an array with 2 elements of type Inner.
Because type Inner contains two arrays whose upper bound depend
on a variable, the size of the array, and therefore the size of
type Inner is dynamic, thus making field A1 a dynamically-size
field.
When trying to print the value of Rt, we hit the following limitation:
(gdb) print rt
Attempt to resolve a variably-sized type which appears in the interior of
a structure type
The limitation was somewhat making sense in C, but needs to be lifted
for Ada. This patch mostly lifts that limitation. As a result of this
patch, the type length computation had to be reworked a little bit.
gdb/ChangeLog:
* gdbtypes.c (resolve_dynamic_struct): Do not generate an error
if detecting a variable-sized field that is not the last field.
Fix struct type length computation.
gdb/testsuite/ChangeLog:
* gdb.base/vla-datatypes.c (vla_factory): Add new variable
inner_vla_struct_object_size.
* gdb.base/vla-datatypes.exp: Adjust last test, and mark it
as xfail.
As reported in PR 17206, an internal error is triggered when command
until is executed. In infcmd.c:until_next_command, step_range_end is
set to 'pc',
if (!func)
{
struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc);
if (msymbol.minsym == NULL)
error (_("Execution is not within a known function."));
tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol);
tp->control.step_range_end = pc;
}
and later in infrun.c:resume, the assert below is triggered in PR
17206.
if (tp->control.may_range_step)
{
/* If we're resuming a thread with the PC out of the step
range, then we're doing some nested/finer run control
operation, like stepping the thread out of the dynamic
linker or the displaced stepping scratch pad. We
shouldn't have allowed a range step then. */
gdb_assert (pc_in_thread_step_range (pc, tp));
}
In until_next_command, we set step range to [XXX, pc), so pc isn't
within the range. pc_in_thread_step_range returns false and the
assert is triggered. AFAICS, the range we want in until_next_command
is [XXX, pc] instead of [XXX, pc), because we want to program step
until greater than pc. This patch is to set step_range_end to
'pc + 1'. Running until-nodebug.exp with unpatched GDB will get the
following fail,
FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error)
and the fail goes away when the fix is applied.
gdb:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* infcmd.c (until_next_command): Set step_range_end to PC + 1.
gdb/testsuite:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* gdb.base/until-nodebug.exp: New.
* guile/scm-param.c (pascm_parameter_defined_p): New function.
(gdbscm_register_parameter_x): Call it. Raise error for pre-existing
parameters.
testsuite/
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.
These tests used to fail on ARM but now pass, so remove the KFAIL.
gdb/testsuite/ChangeLog:
2014-07-28 Will Newton <will.newton@linaro.org>
* gdb.base/varargs.exp: Remove KFAILs for ARM.
* data-directory/Makefile.in (GUILE_FILES): Add support.scm.
* guile/lib/gdb/support.scm: New file.
* guile/guile.c (gdbscm_init_module_name): Change to "gdb".
* guile/lib/gdb.scm: Load gdb/init.scm as an include file.
All uses updated.
* guile/lib/gdb/init.scm (SCM_ARG1, SCM_ARG2): Moved to support.scm.
All uses updated.
(%assert-type): Ditto, and renamed to assert-type.
(%exception-print-style): Delete.
testsuite/
* gdb.guile/types-module.exp: Add tests for wrong type arguments.
Joel Brobecker
Maciej W. Rozycki
Doug Evans
Yao Qi
Gabriel Krisman Bertazi
Jan Kratochvil
Sergio Durigan Junior
Sasha Smundak
Gary Benson
Doug Evans
Pedro Alves
David Blaikie
Siva Chandra
Tom Tromey
Will Newton