Since the last change to address_from_register, it no longer supports
targets that require a special conversion (gdbarch_convert_register_p)
for plain pointer type; I had assumed no target does so.
This turned out to be incorrect: MIPS64 n32 big-endian needs such a
conversion in order to properly sign-extend pointer values.
This patch fixes this regression by handling targets that need a
special conversion in address_from_register as well.
gdb/ChangeLog:
* findvar.c (address_from_register): Handle targets requiring
a special conversion routine even for plain pointer types.
Old AIX versions required GDB to update the stack pointer register and
execute at least one instruction before accessing the space newly allocated
on the user stack. This was done using the exec_one_dummy_insn routine
in rs6000-nat.c
However, in currently supported AIX versions (tested on AIX 6.1), this hack
is no longer necessary. In fact, removing the hack actually fixed several
test case failures, and removes a call to deprecated_insert_raw_breakpoint.
gdb/ChangeLog:
* rs6000-nat.c (exec_one_dummy_insn): Remove.
(store_register): Do not call exec_one_dummy_insn.
Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:
(gdb) p foo.three_ptr.all'first
Location address is not set.
(gdb) p foo.three_ptr.all'length
Location address is not set.
This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type. The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.
Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:
(gdb) p foo.three_ptr'first
Location address is not set.
(gdb) p foo.three_ptr'length
Location address is not set.
This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.
This patch fixes both issues, thus allowing us to get the expected output:
(gdb) p foo.three_ptr.all'first
$1 = 1
(gdb) p foo.three_ptr.all'length
$2 = 3
(gdb) p foo.three_ptr'first
$3 = 1
(gdb) p foo.three_ptr'length
$4 = 3
gdb/ChangeLog:
* ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
dereference it first. Use value_enclosing_type instead of
value_type.
(ada_array_length): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
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.
gdb/ChangeLog:
* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): Pass guile version as
last parameter to pkg-config, not first.
* configure.ac: Pass --with-guile provided pkg-config path to
GDB_GUILE_PROGRAM_NAMES.
* configure: Regenerate.
There are `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' sections
also present in Linux executables, so we can't infer IRIX OS ABI solely
from the existence of these sections. This is not going to be a problem
as there are bound to be other sections whose names start with `.MIPS.'
in IRIX executables and this selection only matters for a non-default OS
ABI in a multiple-target GDB executable. As a last resort the automatic
selection can be overridden with `set osabi'.
* mips-irix-tdep.c (mips_irix_elf_osabi_sniff_abi_tag_sections):
Exclude `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' from
the list of sections determining GDB_OSABI_IRIX.
The trad_frame_set_reg_unknown declaration was added in commit
0db9b4b709 (March 2004), but apparently never defined or referenced.
gdb/ChangeLog:
* trad-frame.h (trad_frame_set_reg_unknown): Remove declaration.
The following patch...
commit 3116063bd6
Date: Fri Jun 27 09:52:29 2014 +0100
Subject: Tidy #include lists
... introduced a build failure on certain x86 GNU/Linux distributions
(reproduced on SuSE 10 and RHES4) due to "struct iovec" not being
defined. This struct is defined in <sys/uio.h>, which used to be
explicitly included, but no longer is after the commit above was
applied.
[...]/i386-linux-nat.c: In function 'fetch_xstateregs':
[...]/i386-linux-nat.c:325:16: error: storage size of 'iov' isn't known
[...]/i386-linux-nat.c: In function 'store_xstateregs':
[...]/i386-linux-nat.c:348:16: error: storage size of 'iov' isn't known
make[2]: *** [i386-linux-nat.o] Error 1
It seems to be working on newer GNU/Linux distros thanks to indirect
inclusion of <sys/uio.h>, but it does not work on some other versions
of the same distros. This is why indirect includes of public APIs
should be avoided if at all possible.
This patch fixes the issue by adding the explicit include back.
gdb/ChangeLog:
* i386-linux-nat.c, x86-linux-nat.c: Add <sys/uio.h> #include.
The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered. The other thread
will see the signal and the sigsuspend won't "wake up".
Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.
gdb/ChangeLog:
PR 17247
* guile.c: #include <signal.h>.
(_initialize_guile): Block SIGCHLD while initializing Guile.
Replaces the following, which is reverted.
2014-07-26 Doug Evans <xdje42@gmail.com>
PR 17185
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
gdb/ChangeLog:
* guile/scm-cmd.c (gdbscm_parse_command_name): Replace magic number
with named constant. Fix style of pointer comparison.
* python/py-cmd.c (gdbpy_parse_command_name): Ditto.
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.
valgrind caught that parse_number reads uninitialized memory when we
parse literal "0":
$ valgrind ./gdb -q -nx -ex "set height 0"
(...)
==10378== Conditional jump or move depends on uninitialised value(s)
==10378== at 0x548A10: parse_number (c-exp.y:1828)
==10378== by 0x54A340: lex_one_token (c-exp.y:2638)
==10378== by 0x54B4BB: c_lex (c-exp.y:3089)
==10378== by 0x544951: c_parse_internal (c-exp.c:2208)
==10378== by 0x54BF8C: c_parse (c-exp.y:3260)
==10378== by 0x6502E7: parse_exp_in_context_1 (parse.c:1221)
==10378== by 0x650064: parse_exp_in_context (parse.c:1122)
==10378== by 0x65001F: parse_exp_1 (parse.c:1114)
==10378== by 0x650421: parse_expression (parse.c:1266)
==10378== by 0x5A74B7: parse_and_eval_long (eval.c:92)
==10378== by 0x501ABD: do_set_command (cli-setshow.c:302)
==10378== by 0x721059: execute_command (top.c:452)
==10378==
(gdb)
I've pushed the obvious fix.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
* c-exp.y (parse_number): Skip handling base-switching prefixes if
the input is only one character long.
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.
Historically the Linux x86 watchpoint code did not cope with multi-
threaded processes and LWP IDs were passed to it wrapped as PIDs.
Not all entry points were converted when the Linux x86 watchpoint
code was made multi-thread-aware, so a handler was left in place to
cope with wrapped LWPs. Since then all such entry points have been
converted to pass regular LWPs and the handler is now redundant.
This commit removes the handler and adds assertions to ensure no
wrapped LWPs are passed in future.
gdb/ChangeLog:
* x86-linux-nat.c (x86_linux_dr_get, x86_linux_dr_set):
Remove code to cope with LWPs wrapped as PIDs.
Add assertions to ensure no wrapped LWPs are passed.
Git 9a0dc9e3 regressed gdb.dwarf2/pieces-optimized-out.exp, visible on
i686 (the test doesn't run on x86_64):
(gdb) p s
-$1 = {a = 5, b = <optimized out>, c = <optimized out>, d = <optimized out>}
+$1 = {a = 5, b = <optimized out>, c = 0, d = 0}
-(gdb) PASS: gdb.dwarf2/pieces-optimized-out.exp: print s
+(gdb) FAIL: gdb.dwarf2/pieces-optimized-out.exp: print s
The regression was caused by this removal in cp-valprint.c:
@@ -293,12 +293,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
{
fputs_filtered (_("<synthetic pointer>"), stream);
}
- else if (!value_bits_valid (val,
- TYPE_FIELD_BITPOS (type, i),
- TYPE_FIELD_BITSIZE (type, i)))
- {
- val_print_optimized_out (val, stream);
- }
else
{
struct value_print_options opts = *options;
The idea was that we'd just fallback to calling value_field_bitfield,
which handles unavailable values (in unpack_value_bits_as_long_1) so
should be able to handle optimized out values too. Alas, it doesn't.
This is currently a bit too messy. Instead of teaching
unpack_value_bits_as_long_1 about optimized out bits, let's bite the
bullet and teach the value code to handle partially optimized out
bitfield, by having it unpack a bitfield and then propagate the range
metadata. Turns out the resulting code looks simpler and clearer.
Tested on x86_64 Fedora 20, -m64/-m32.
gdb/ChangeLog:
* value.c (value_ranges_copy_adjusted): New function, factored out
from ...
(value_contents_copy_raw): ... here.
(unpack_value_bits_as_long_1): Rename back to ...
(unpack_bits_as_long): ... this. Remove 'original_value' and
'result' parameters. Change return type to LONGEST.
(unpack_value_bits_as_long): Delete.
(unpack_value_field_as_long_1): Delete.
(unpack_value_field_as_long, unpack_field_as_long): Reimplement.
(unpack_value_bitfield): New function.
(value_field_bitfield): Reimplement using unpack_value_bitfield.
(value_fetch_lazy): Use unpack_value_bitfield.
* value.h (unpack_value_bits_as_long): Delete declaration.
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.
PTRACE_PEEKUSER can return -1, which is usually used to determine whether
a system call has reported an error, so errno must be used alone to
determine whether an error occurred. However errno isn't modified by a
successful system call so it must be reset to a known value (0) before the
syscall call.
Add the missing errno reset when reading the DSP_CONTROL register in the
native MIPS Linux backend and the MIPS gdbserver backend.
gdb/:
* mips-linux-nat.c (mips_linux_read_description): Reset errno to 0
prior to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
gdb/gdbserver/:
* linux-mips-low.c (mips_read_description): Reset errno to 0 prior
to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
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.
The loop macro ALL_DEBUG_REGISTERS does not iterate over the status or
control registers, so its name is misleading. This commit renames it
as ALL_DEBUG_ADDRESS_REGISTERS and updates all uses. This commit also
updates its loop conditions to an equivalent but better form, and
makes two functions use it that had previously hardwired the loop.
A comment on a related field in the x86_debug_reg_state structure is
also updated to reflect that the field refers specifically to address
registers only.
gdb/ChangeLog:
* nat/x86-dregs.h (ALL_DEBUG_REGISTERS): Renamed as...
(ALL_DEBUG_ADDRESS_REGISTERS): New macro. All uses updated.
Loop conditions changed to equivalent form.
(struct x86_debug_reg_state): Updated dr_ref_count comment.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
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.
This commit creates a new file, common/gdb_setjmp.h, to hold some
portability macros for setjmp/longjmp et al. that are used by the
exceptions subsystem and by the demangler crash catcher.
gdb/ChangeLog:
* common/gdb_setjmp.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/gdb_setjmp.h.
* configure.ac: Move sigsetjmp check...
* common/common.m4: ...here.
* configure: Regenerate.
* cp-support.c (SIGJMP_BUF): Delete.
(SIGSETJMP): Likewise.
(SIGLONGJMP): Likewise.
* exceptions.h (gdb_setjmp.h): Include.
(setjmp.h): Do not include.
(EXCEPTIONS_SIGJMP_BUF): Delete.
(EXCEPTIONS_SIGSETJMP): Likewise.
(EXCEPTIONS_SIGLONGJMP): Likewise.
Replace all uses of EXCEPTIONS_SIG* macros with SIG* macros
from gdb_setjmp.h.
* exceptions.c: Likewise.
gdb/gdbserver/ChangeLog:
* config.in: Regenerate.
* configure: Likewise.
This commit moves cleanups.[ch] into gdb/common/. The only change to
the content of the files is that cleanups.c's include list was altered
to match its new location.
gdb/ChangeLog:
* cleanups.h: Moved to...
* common/cleanups.h: New file.
* cleanups.c: Moved to...
* common/cleanups.c: New file. Include common-defs.h and
cleanups.h. Do not include defs.h.
* Makefile.in (SFILES): Replace cleanups.c with common/cleanups.c.
(HFILES_NO_SRCDIR): Replace cleanups.h with common/cleanups.h.
(cleanups.o): New rule.
gdb/gdbserver/ChangeLog:
* Makefile.in (SFILES): Add common/cleanups.c.
(OBS): cleanups.o.
(cleanups.o): New rule.
Various warnings are emitted during startup and option-parsing using
fprintf_unfiltered. One warning is prefixed with the command name,
the others are not. This commit replaces these hardwired warnings
with calls to warning. It also sets warning_pre_print to prefix all
warnings with the command name until option parsing is complete.
gdb/ChangeLog:
* main.c (captured_main): Use warning during startup.
Prefix startup warning messages with command name.
This commit replaces the hardwired fprintf/exit error handlers
for usage errors with calls to error.
gdb/ChangeLog:
* main.c (captured_main): Handle usage errors with error.
go32_create_inferior invokes a hardwired fprintf/exit error handler
if v2loadimage fails. I could find no reason for this other than that
the block seems to have been copy-and-pasted from v2loadimage's
manpage. This commit replaces the hardwired handler with a call to
error.
gdb/ChangeLog:
* go32-nat.c (go32_create_inferior): Replace a fprintf/
exit pair with a call to error. Wrap the message with _().
If the requested interpreter cannot be set captured_main reports the
error with a hardwired fprintf/exit pair. A fprintf/exit pair on the
previous line was replaced with a call to error in March 2003
(https://sourceware.org/ml/gdb-patches/2003-03/msg00444.html) but I
found no documentation as to why this particular hardwired handler
was left untouched. I was also unable to come up with a situation
where error would not be suitable, so I have replaced it with a call
to error.
gdb/ChangeLog:
* main.c (captured_main): Replace a fprintf/exit
pair with a call to error. Wrap the message with _().
tui_initialize_io contains a pair of hardwired fprintf/exit error
handlers. I was unable to find any documentation as to why they're
hardwired (the code appeared in a monolithic block back in 2001:
https://sourceware.org/ml/gdb-patches/2001-07/msg00490.html) and I
was also unable to come up with a situation where error would not
be suitable, so I have replaced both handlers with calls to error.
gdb/ChangeLog:
* tui/tui-io.c (tui_initialize_io): Replace two fprintf/exit
pairs with calls to error. Wrap the message with _().
warning will crash if called before the first call to set_width. This
commit makes the warning usable from the moment gdb_stderr is set up.
gdb/ChangeLog:
* utils.c (vwarning): Protect calls to target_terminal_ours
and wrap_here.
error (and other exception-throwing functions) are callable from the
first line of captured_main, but the exception printing code will
crash if called before the first call to set_width. This commit makes
the exception printing code usable from the moment gdb_stderr is set
up.
gdb/ChangeLog:
* exceptions.c (print_flush): Protect calls to
target_terminal_ours and wrap_here.
internal_vproblem can be called (via malloc_failure) from almost the
first line of captured_main, but it will crash if called before the
first call to set_width. This commit makes internal_vproblem work
at any time.
There are two parts to this. If called before gdb_stderr is set up,
internal_vproblem will fall back to printing the message on regular
stderr and aborting. If called after gdb_stderr is set up but before
filtered printing is set up, internal_vproblem will operate as usual
except that it can not query whether to quit and/or dump core so it
defaults to doing both.
gdb/ChangeLog:
* utils.h (filtered_printing_initialized): New declaration.
* utils.c (abort_with_message): New function.
(internal_vproblem): Use abort_with_message for first level
recursive internal problems, and if gdb_stderr is not set up.
Protect calls to target_terminal_ours, begin_line and query.
Hi,
This patch is to handle a software watchpoint case that program returns
to caller's epilogue, and it causes the fail in thumb mode,
finish^M
Run till exit from #0 func () at gdb/testsuite/gdb.base/watchpoint-cond-gone.c:26^M
0x000001f6 in jumper ()^M
(gdb) FAIL: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
In the test, jumper calls func, and programs returns from func to
jumper's epilogue, IOW, the branch instruction is the last instruction
of jumper's function body.
jumper:
.....
0x000001f2 <+10>: bl 0x200 [1] <---- indirect call to func
0x000001f6 <+14>: mov sp, r7 [2] <---- start of the epilogue
0x000001f8 <+16>: add sp, #8
0x000001fa <+18>: pop {r7}
0x000001fc <+20>: pop {r0}
0x000001fe <+22>: bx r0
When the inferior returns from func back to jumper, it is expected
that an expression of a software watchpoint becomes out-of-scope.
GDB validates the expression by checking the corresponding frame,
but this check is guarded by gdbarch_in_function_epilogue_p. See
breakpoint.c:watchpoint_check.
It doesn't work in this case, because program returns from func's
epilogue back to jumper's epilogue [2], GDB thinks the program is
still within the epilogue, but in fact it goes to a different one.
When PC points at [2], the sp-restore instruction is to be
executed, so the stack frame isn't destroyed yet and we can still
use the frame mechanism reliably.
Note that when PC points to the first instruction of restoring SP,
it is part of epilogue, but we still return zero. When goes to
the next instruction, the backward scan will still match the
epilogue sequence correctly. The reason for doing this is to
handle the "return-to-epilogue" case.
What this patch does is to restrict the epilogue matching that let
GDB think the first SP restore instruction isn't part of the epilogue,
and fall back to use frame mechanism. We set 'found_stack_adjust'
zero before backward scan, and we've done this for arm mode
counterpart (arm_in_function_epilogue_p) too.
The patch is tested in arm-none-eabi and arm-none-linux-gnueabi with
various multilibs. OK to apply?
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Don't set
found_stack_adjust in forward scan. Remove condition check
on found_stack_adjust which is always true. Indent the code.
Hi,
dwarf_decode_lines is called in two functions,
dwarf2_build_include_psymtabs and handle_DW_AT_stmt_list, in which, 1
is passed to argument 'want_line_info' and 'want_line_info' is a
conditional variable in dwarf_decode_lines. We can simplify it by
removing 'want_line_info' and propagating the constant 1 into
dwarf_decode_lines. This is what this patch does. This patch also
remove one line comment about WANT_LINE_INFO in
handle_DW_AT_stmt_list, as handle_DW_AT_stmt_list doesn't have such
argument.
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Remove comment about WANT_LINE_INFO.
(dwarf_decode_lines): Remove argument
want_line_info. Remove condition check on want_line_info.
Callers update.
Ulrich Weigand
Joel Brobecker
Doug Evans
Gabriel Krisman Bertazi
Maciej W. Rozycki
James Hogan
Jan Kratochvil
Sergio Durigan Junior
Pedro Alves
Gary Benson
Sasha Smundak
Doug Evans
Yao Qi