I noticed a while ago that the rx-elf gas gprel test regressed for no
apparent reason. It turns out that the problem was rx-parse.y using
BFD_RELOC_RX_* values, which may change when other targets add new
relocs. If rx-parse.o doesn't depend on bfd.h, it won't be recompiled.
* Makefile.am (EXTRA_as_new_SOURCES): Add config/rl78-parse.y and
config/rx-parse.y. Move config/bfin-parse.y.
(bfin-parse.@OBJEXT@, rl78-parse.@OBJEXT@, rx-parse.@OBJEXT@): Delete.
($(srcdir)/config/rl78-defs.h): New rule.
* Makefile.in: Regenerate.
0a69eedb (Clean up the XML files for ARM) moves arm-*.xml files to
arm/ directory, so need update gdb.xml/tdesc-regs.exp accordingly.
gdb/testsuite:
2016-10-07 Yao Qi <yao.qi@linaro.org>
* gdb.xml/tdesc-regs.exp: Set regdir to "arm/".
The gdb.decode_line python function is documented to support the same location
expressions as the "break" command. It currently expects a linespec location.
Instead of creating a linespec location directly, create the location via
string_to_event_location_basic.
This simple commit consolidates the API of
target_supports_multi_process. Since both GDB and gdbserver use the
same function prototype, all that was needed was to move create this
prototype on gdb/target/target.h and turn the macros declared on
gdb/{,gdbserver/}target.h into actual functions.
Regtested (clean pass) on the BuildBot.
gdb/ChangeLog:
2016-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* target.c (target_supports_multi_process): New function, moved
from...
* target.h (target_supports_multi_process): ... here. Remove
macro.
* target/target.h (target_supports_multi_process): New prototype.
gdb/gdbserver/ChangeLog:
2016-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* target.c (target_supports_multi_process): New function, moved
from...
* target.h (target_supports_multi_process): ... here. Remove
macro.
Fixes this failure when building in C mode. I think it's relevant for master
as well, since it's a good practice to include (or forward-declare) what you
use.
In file included from ../../binutils-gdb/gdb/gdbarch.h:38:0,
from ../../binutils-gdb/gdb/defs.h:653,
from ../../binutils-gdb/gdb/dictionary.c:23:
../../binutils-gdb/gdb/frame.h:710:48: warning: ‘struct ui_out’ declared inside parameter list will not be visible outside of this definition or declaration
extern void print_stack_frame_to_uiout (struct ui_out *uiout,
gdb/ChangeLog:
* frame.h: Forward-declare struct ui_out.
Fix a regression from commit f8b73d13b7 ("Target-described register
support for MIPS"),
<https://sourceware.org/ml/gdb-patches/2007-05/msg00340.html>,
<https://sourceware.org/ml/gdb-patches/2007-06/msg00256.html>, which
caused Floating Point Control Registers (FCRs) to be shown as 64-bit
with 64-bit targets.
This came from the legacy register format where all raw registers
matched the width of the architecture regardless of their actual size.
The correct size was then set in `mips_register_type' for cooked
registers presented to the user, which in the case of FCRs meant the
cooked size was always forced to 32 bits, reflecting their actual
hardware size, even though the raw format carried them in 64-bit
quantities on 64-bit targets. The upper 32 bits carried in the raw FCR
format have always been don't-cares, not actually retrieved from
hardware and never written back.
With the introduction of XML register descriptions the layout of
previously defined raw registers has been preserved, so as to keep
existing register handling code unchanged and make it easier for GDB and
`gdbserver' to interact with each other whether neither, either or both
parties talking over RSP support XML register descriptions. For the
XML-described case however `mips_register_type' is not used in raw to
cooked register conversion, so any special cases coded there are not
taken into account.
Instead a new function, `mips_pseudo_register_type', has been introduced
to handle size conversion, however lacking the special case for FCRs for
the Linux and the now defunct IRIX target. The correct size has been
maintained for embedded targets however, due to the bundling of FCRs
with the embedded registers under the `rawnum >= MIPS_EMBED_FP0_REGNUM +
32' condition.
Add the missing case to `mips_pseudo_register_type' then, referring to
the FCR indices explicitly, and observing that between
`MIPS_EMBED_FP0_REGNUM + 32' and `MIPS_FIRST_EMBED_REGNUM' there is an
unused register slot whose contents are ignored so with the removal of
embedded FCRs from under that condition we don't have to care about it
and we can refer to the embedded registers starting from
MIPS_FIRST_EMBED_REGNUM instead.
Add a test case too so that we have means to check automatically that
the correct user-visible size of FCRs is maintained.
gdb/
* mips-tdep.c (mips_pseudo_register_type): Make FCRs always
32-bit.
gdb/testsuite/
* gdb.arch/mips-fcr.exp: New test.
* gdb.arch/mips-fcr.c: Source for the new test.
Rearrange comments throughout `mips_pseudo_register_type', placing them
ahead the condtionals they apply to consistently.
gdb/
* mips-tdep.c (mips_pseudo_register_type): Rearrange comments
throughout.
Correct a commit 2151ccc56c ("Always organize test artifacts in a
directory hierarchy") regression causing:
Running .../gdb/testsuite/gdb.base/solib-disc.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.base/so-disc-shr.c.o: No such file or directory
by using `standard_output_file' to construct output file names
throughout.
gdb/testsuite/
* gdb.base/solib-disc.exp: Use `standard_output_file'
throughout.
Commit a038fa3e14 stack: check frame_unwind_caller_id adds a frame_id check to
frame_info and treats a missing frame_id as NOT_AVAILABLE_ERROR. This causes a
regression in gdb.dwarf2/dw2-undefined-ret-addr.exp.
Treat a missing frame_id as OPTIMIZED_OUT_ERROR instead.
See also https://sourceware.org/ml/gdb-patches/2016-07/msg00273.html.
The comment logically belongs inside the preprocessor conditional,
but gcc's -Wimplicit-fallthrough loses track of it. Revert when/if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817 is fixed.
* app.c (do_scrub_chars): Move fall through comment.
* expr.c (operand): Likewise.
Even though this was supposedly in the gdb 7.2 timeframe, the testcase
in PR11094 crashes current GDB with a segfault:
Program received signal SIGSEGV, Segmentation fault.
0x00000000005ee894 in event_location_to_string (location=0x0) at
src/gdb/location.c:412
412 if (EL_STRING (location) == NULL)
(top-gdb) bt
#0 0x00000000005ee894 in event_location_to_string (location=0x0) at
src/gdb/location.c:412
#1 0x000000000057411a in print_breakpoint_location (b=0x18288e0, loc=0x0) at
src/gdb/breakpoint.c:6201
#2 0x000000000057483f in print_one_breakpoint_location (b=0x18288e0,
loc=0x182cf10, loc_number=0, last_loc=0x7fffffffd258, allflag=1)
at src/gdb/breakpoint.c:6473
#3 0x00000000005751e1 in print_one_breakpoint (b=0x18288e0,
last_loc=0x7fffffffd258, allflag=1) at
src/gdb/breakpoint.c:6707
#4 0x000000000057589c in breakpoint_1 (args=0x0, allflag=1, filter=0x0) at
src/gdb/breakpoint.c:6947
#5 0x0000000000575aa8 in maintenance_info_breakpoints (args=0x0, from_tty=0)
at src/gdb/breakpoint.c:7026
[...]
This is GDB trying to print the location spec of the JIT event
breakpoint, but that's an internal breakpoint without one.
If I add a NULL check, then we see that the JIT breakpoint is now
pending (because its location has shlib_disabled set):
(gdb) maint info breakpoints
Num Type Disp Enb Address What
[...]
-8 jit events keep y <PENDING> inf 1
[...]
But that's incorrect. GDB should have managed to recreate the JIT
breakpoint's location for the second run. So the problem is
elsewhere.
The problem is that if the JIT loads at the same address on the second
run, we never recreate the JIT breakpoint, because we hit this early
return:
static int
jit_breakpoint_re_set_internal (struct gdbarch *gdbarch,
struct jit_program_space_data *ps_data)
{
[...]
if (ps_data->cached_code_address == addr)
return 0;
[...]
delete_breakpoint (ps_data->jit_breakpoint);
[...]
ps_data->jit_breakpoint = create_jit_event_breakpoint (gdbarch, addr);
Fix this by deleting the breakpoint and discarding the cached code
address when the objfile where the previous JIT breakpoint was found
is deleted/unloaded in the first place.
The test that was originally added for PR11094 doesn't trip on this
because:
#1 - It doesn't test the case of the JIT descriptor's address _not_
changing between reruns.
#2 - And then it doesn't do "maint info breakpoints", or really
anything with the JIT at all.
#3 - and even then, to trigger the problem the JIT descriptor needs
to be in a separate library, while the current test puts it in
the main program.
The patch extends the test to cover all combinations of these
scenarios.
gdb/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* jit.c (free_objfile_data): Delete the JIT breakpoint and clear
the cached code address.
gdb/testsuite/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* gdb.base/jit-simple-dl.c: New file.
* gdb.base/jit-simple-jit.c: New file, factored out from ...
* gdb.base/jit-simple.c: ... this.
* gdb.base/jit-simple.exp (jit_run): Delete.
(build_jit): New proc.
(jit_test_reread): Recompile either the main program or the shared
library, depending on what is being tested. Skip changing address
if caller wants to. Compare before/after addresses. If testing
standalone, explicitly load the binary. Test "maint info
breakpoints".
(top level): Add "standalone vs shared lib" and "change address"
vs "same address" axes.
I noticed that we sometimes get this:
(gdb) print &__jit_debug_descriptor
$1 = (struct jit_descriptor *) 0x601040 <__jit_debug_descriptor>
(gdb) PASS: gdb.base/jit-simple.exp: blah 1
[...]
(gdb) run
[...]
Starting program: build/gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple
Unsupported JIT protocol version 4 in descriptor (expected 1)
Breakpoint 2, main () at src/gdb/testsuite/gdb.base/jit-simple.c:36
36 return 0;
(gdb) print &__jit_debug_descriptor
$2 = (struct jit_descriptor *) 0x601040 <__jit_debug_descriptor>
(gdb) PASS: gdb.base/jit-simple.exp: blah 1
All tests PASSed, but note the "Unsupported JIT protocol version 4"
message.
Also notice that "__jit_debug_descriptor" has the same address before
and after the rerun, while the test is built in a way that should make
that address change between runs.
The test doesn't catch any of this because it doesn't compare
before/after addresses.
And then notice the "blah 1" test messages. "blah" is clearly a WIP
message, but it should be at least "blah 2" the second time. :-)
The reason this sometimes happens is that the test recompiles the
program and expects gdb to reload it automaticallyt on "run". However,
if the original program and the new recompilation happen to be in the
same second, then gdb does not realize that the binary needs to be
reloaded. (This is an old problem out of scope of this series.) If
that happens, then GDB ends up using the wrong symbols for the program
that it spawns, reads the JIT descriptor out of the wrong address,
finds garbage, and prints that "unsupported version" notice.
Fix that in the same way gdb.base/reread.exp handles it -- by sleeping
one second before recompiling.
gdb/testsuite/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* gdb.base/jit-simple.exp (top level) Delete get_compiler_info
call.
(jit_run): Delete.
(jit_test_reread): Use with_test_prefix. Reload the main binary
explicitly. Compare the before/after addresses of the JIT
descriptor.
The .cfi_sections directive can be safely used multiple times
with different sections named at any time unless the compact form
of exception handling is requested after CFI information has
been emitted. Only the compact form of CFI information changes
the way in which CFI is generated and therefore cannot be
retrospectively requested after generating CFI information.
gas/
PR gas/20648
* dw2gencfi.c (dot_cfi_sections): Refine the check for
inconsistent .cfi_sections to only consider compact vs non
compact forms.
* testsuite/gas/cfi/cfi-common-9.d: New file.
* testsuite/gas/cfi/cfi-common-9.s: New file.
* testsuite/gas/cfi/cfi.exp: Run new test.
Newer gdbservers may be talking to older gdbs,
and older gdbs will flag a missing "end" as an error.
So just make "end" required again, and for compatibility
change the default field type to "bool".
gdb/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* features/aarch64-core.xml (cpsr_flags): Elide "type" and specify
"end" in all fields.
* features/aarch64.c: Regenerate.
* features/i386/32bit-mpx.xml (_bndcfgu): Specify type of "preserved"
and "enabled" fields. Correct size of "enabled" field.
* features/i386/64bit-mpx.xml (_bndcfgu): Specify type of "preserved"
and "enabled" fields.
* features/i386/i386-avx-mpx-linux.c: Regenerate.
* features/i386/i386-avx-mpx.c: Regenerate.
* features/i386/i386-avx512-linux.c: Regenerate.
* features/i386/i386-avx512.c: Regenerate.
* features/i386/i386-mpx-linux.c: Regenerate.
* features/i386/i386-mpx.c: Regenerate.
* features/arc-arcompact.c: Regenerate.
* features/arc-v2.c: Regenerate.
* xml-tdesc.c (tdesc_start_field): Require "end" spec. Single bit
fields default to "bool" type.
Revert 2016-03-15 Doug Evans <dje@google.com>
* features/i386/32bit-core.xml (i386_eflags): Remove "end" spec.
* features/i386/32bit-sse.xml (i386_eflags): Ditto.
* features/i386/64bit-core.xml (i386_eflags): Ditto.
* features/i386/64bit-sse.xml (i386_eflags): Ditto.
* features/i386/x32-core.xml (i386_eflags): Ditto.
gdb/doc/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* gdb.texinfo (Target Description Format): Update docs on "end"
field spec and field default type.
gdb/testsuite/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* gdb.xml/extra-regs.xml: Update, end field now required, default type
for single bitfields is bool.
* gdb.xml/tdesc-regs.exp: Ditto.
bfd/
* elf32-epiphany.c (epiphany_final_link_relocate): Use bitwise
OR in arithmetic expression, not boolean OR.
opcodes/
* cr16-dis.c (print_insn_cr16): Don't use boolean OR in arithmetic.
* crx-dis.c (print_insn_crx): Likewise.
gcc-6.2.1-2.fc24.x86_64
(gdb) backtrace 10^M
(gdb) FAIL: gdb.arch/i386-signal.exp: backtrace 10
(gdb) disas/s
Dump of assembler code for function main:
.../gdb/testsuite/gdb.arch/i386-signal.c:
30 {
0x000000000040057f <+0>: push %rbp
0x0000000000400580 <+1>: mov %rsp,%rbp
31 setup ();
0x0000000000400583 <+4>: callq 0x400590 <setup>
=> 0x0000000000400588 <+9>: mov $0x0,%eax
32 }
0x000000000040058d <+14>: pop %rbp
0x000000000040058e <+15>: retq
End of assembler dump.
The .exp patch is an obvious typo fix I think. The regex was written to
accept "ADDR in main" and I find it OK as checking .debug_line validity is not
the purpose of this testfile.
gcc-4.8.5-11.el7.x86_64 did not put the 'mov $0x0,%eax' instruction there at
all so there was no problem with .debug_line.
gdb/testsuite/ChangeLog
2016-10-05 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-signal.exp (backtrace 10): Fix#2 typo.
handle_tracepoint_bkpts has two parallel "if"s. This changes the
second one to check ipa_error_tracepoint, which seems to be what was
intended.
2016-10-05 Tom Tromey <tom@tromey.com>
PR remote/20655:
* tracepoint.c (handle_tracepoint_bkpts): Check
ipa_error_tracepoint, not ipa_stopping_tracepoint.
This bug points out that string_to_explicit_location compares a char*
against '\0'; whereas comparing against NULL is more normal.
2016-10-05 Tom Tromey <tom@tromey.com>
PR breakpoints/20653:
* location.c (string_to_explicit_location): Use NULL, not '\0'.
This fixes an oversight in psymbol_compare.
2016-10-05 Tom Tromey <tom@tromey.com>
PR symtab/20652:
* psymtab.c (psymbol_compare): Correctly compare "ginfo.value"
fields.
If the target doesn't support float, we don't run float complex types
tests.
gdb/testsuite:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (support_complex_tests): Return zero if
gdb_skip_float_test return true.
In DWARF expression handling, some operators are required to be either
at the end of an expression or followed by a composition operator. So
far only the operators DW_OP_reg0-31 were allowed to be followed by
DW_OP_GNU_uninit instead, and particularly DW_OP_regx was not, which is
obviously inconsistent.
This patch allows DW_OP_GNU_uninit after all operators requiring a
composition, to simplify the code and make it more consistent. This
policy may be more permissive than necessary, but in the worst case just
leads to a DWARF location description resulting in an uninitialized
value instead of an error message.
gdb/ChangeLog:
* dwarf2expr.c (dwarf_expr_require_composition): Allow
DW_OP_GNU_uninit.
(execute_stack_op): Use dwarf_expr_require_composition instead of
copying its logic.
The logging message is called too often - once for each register when it's
value has to be evaluated. This floods the screen for commands like "info
register all", but doesn't give really any help at debugging GDB issues.
Between increasing the debug level of this message and removing it altogether I
think that removing it is preferable.
gdb/ChangeLog:
arc-tdep.c (arc_frame_prev_register): Remove annoying log message.
0a69eedb (Clean up the XML files for ARM) breaks the GDBserver build
on aarch64 because some arm-*.xml files can't be found.
This patch is to fix the build failure.
gdb/gdbserver:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* configure.srv: Update the path of arm-*.xml files.
If I remove all regformats/*.dat files and run
make GDB=/scratch/yao/gdb/build-git/all-targets/gdb/gdb all, some
powerpc .dat files are not generated.
This patch fixes it by adding them to WHICH, so these .dat files can
be generated.
gdb:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* features/Makefile (WHICH): Add
rs6000/powerpc-isa205-32l, rs6000/powerpc-isa205-64l,
rs6000/powerpc-isa205-altivec32l, rs6000/powerpc-isa205-altivec64l,
rs6000/powerpc-isa205-vsx32l and rs6000/powerpc-isa205-vsx64l.
* regformats/rs6000/powerpc-isa205-32l.dat: Regenerated.
* regformats/rs6000/powerpc-isa205-64l.dat: Likewise.
* regformats/rs6000/powerpc-isa205-altivec32l.dat: Likewise.
* regformats/rs6000/powerpc-isa205-altivec64l.dat: Likewise.
* regformats/rs6000/powerpc-isa205-vsx32l.dat: Likewise.
* regformats/rs6000/powerpc-isa205-vsx64l.dat: Likewise.
If I delete all target description c files under features/ directory,
and run make GDB=/scratch/yao/gdb/build-git/all-targets/gdb/gdb cfiles,
some s390 target description c files are not generated.
This patch adds these s390 xml files to XMLTOC, so these c files can
be generated.
gdb:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* features/Makefile (XMLTOC): Add s390-tevx-linux64.xml,
s390-vx-linux64.xml, s390x-tevx-linux64.xml and
s390x-vx-linux64.xml.
