* gdbtypes.c (create_static_range_type): Renamed from create_range_type.
* gdbtypes.h (create_static_range_type): Renamed from create_range_type.
* ada-lang.c: All uses of create_range_type updated.
* coffread.c: All uses of create_range_type updated.
* dwarf2read.c: All uses of create_range_type updated.
* f-exp.y: All uses of create_range_type updated.
* m2-valprint.c: All uses of create_range_type updated.
* mdebugread.c: All uses of create_range_type updated.
* stabsread.c: All uses of create_range_type updated.
* valops.c: All uses of create_range_type updated.
* valprint.c: All uses of create_range_type updated.
Doug told me that there are some regressions in gdb.base/completion.exp.
They are caused by my recent change, and can be reproduced via:
$ make check-parallel TESTS=gdb.base/completion.exp
FAIL: gdb.base/completion.exp: complete target core ./gdb.base/completion
FAIL: gdb.base/completion.exp: complete target tfile ./gdb.base/completion
FAIL: gdb.base/completion.exp: complete target exec ./gdb.base/completion
Current tests assume that gdb.base/completion exists but that is wrong
in a parallel run, because binary file and object files are placed
in outputs/gdb.base/completion/.
This patch is to check file exists on two candidate directories,
"gdb.base" and "outputs/gdb.base/completion/", and run tests with files
existed in either of them.
gdb/testsuite:
2014-04-11 Yao Qi <yao@codesourcery.com>
* gdb.base/completion.exp: Check file exists before running tests
on file completion.
While trying to fix hbreak2.exp against GDBserver I noticed this...
(gdb) hbreak main if 1
Sending packet: $m400580,40#2e...Packet received: e8d2ffffff5dc3554889e54883ec10c745fc00000000eb0eb800000000e8c1ffffff8345fc01817dfce70300007ee9b800000000c9c3662e0f1f840000000000
Sending packet: $m40058f,1#31...Packet received: c7
Hardware assisted breakpoint 1 at 0x40058f: file ../../../src/gdb/testsuite/gdb.base/break-idempotent.c, line 46.
Sending packet: $Z1,40058f,1;X3,220127#9b...
*hangs forever*
The issue is that nothing advances the packet pointer if
add_breakpoint_condition either fails to parse the agent expression,
or fails to find the breakpoint, resulting in an infinite loop in
process_point_options. The latter case should really be fixed by
GDBserver tracking GDB Z1 breakpoints in its breakpoint structures
like Z0 breakpoints are, but the latter case still needs handling.
add_breakpoint_commands has the same issue, though at present I don't
know any way to trigger it other than sending a manually cooked
packet.
Unbelievably, it doesn't look like we have any test that tries setting
a conditional hardware breakpoint. Looking at cond-eval-mode.exp, it
looks like the file was meant to actually test something, but it's
mostly empty today. This patch adds tests that tries all sorts of
conditional breakpoints and watchpoints. The test hangs/fails without
the GDBserver fix.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2014-04-10 Pedro Alves <palves@redhat.com>
* mem-break.c (add_breakpoint_condition, add_breakpoint_commands):
Check if the condition or command is NULL before checking if the
breakpoint is known. On success, return true.
* mem-break.h (add_breakpoint_condition): Document return.
(add_breakpoint_commands): Add describing comment.
* server.c (skip_to_semicolon): New function.
(process_point_options): Use it.
gdb/testsuite/
2014-04-10 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.c: New file.
* gdb.base/cond-eval-mode.exp: Use standard_testfile. Adjust
prepare_for_testing to build the new file. Check result of
runto_main.
(test_break, test_watch): New procedures.
(top level): Use them.
Breakpoints are supposed to be transparent to memory accesses. For
all kinds of breakpoints breakpoint_xfer_memory hides the breakpoint
instructions. However, sss breakpoints aren't tracked like all other
breakpoints, and nothing is taking care of hiding them from memory
reads.
Say, as is, a background step + disassemble will see breakpoints
instructions on software step targets. E.g., stepping over this line:
while (1);
with s&
and then "disassemble" would show sss breakpoints.
Actually, that's still not be possible to see today, because:
- in native Linux, you can't read memory while the program
is running.
- with Linux gdbserver, you can, but in the all-stop RSP you
can't talk to the server while the program is running...
- and with non-stop, on software step targets, we presently
force the use of displaced-stepping for all single-steps,
so no single-step breakpoints are used...
I've been working towards making non-stop not force displaced stepping
on sss targets, and I noticed the issue then. With that, I indeed see
this:
(gdb) set remote Z-packet off
(gdb) s&
(gdb) disassemble main
Dump of assembler code for function main:
0x000000000040049c <+0>: push %rbp
0x000000000040049d <+1>: mov %rsp,%rbp
0x00000000004004a0 <+4>: int3
0x00000000004004a1 <+5>: (bad)
End of assembler dump.
Instead of the correct:
(gdb) disassemble main
Dump of assembler code for function main:
0x000000000040049c <+0>: push %rbp
0x000000000040049d <+1>: mov %rsp,%rbp
0x00000000004004a0 <+4>: jmp 0x4004a0 <main+4>
This is actually one thing that my v1 of the recent "fix a bunch of
run control bugs" series was fixing, because it made sss breakpoints
be regular breakpoints in the breakpoint chain. But dropped it in the
version that landed in the tree, due to some problems.
So instead of making sss breakpoints regular breakpoints, go with a
simpler fix (at least for now) -- make breakpoint_xfer_memory take
software single-step breakpoints into account. After the patch, I get
the correct disassemble output.
Tested on x86_64 Fedora 17, and also on top of my "use software
single-step on x86" series.
Also fixes the issue pointed out by Yao at
https://sourceware.org/ml/gdb-patches/2014-04/msg00045.html, where the
prologue analysis/frame sniffing manages to see software step
breakpoint instructions.
gdb/
2014-04-10 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoints)
(single_step_gdbarch): Move up in the file.
(one_breakpoint_xfer_memory): New function, factored out from ...
(breakpoint_xfer_memory): ... here. Also process single-step
breakpoints.
sh-linux-gnu-gcc (...) src/gdb/gdbserver/linux-low.c
.../src/gdb/gdbserver/linux-low.c: In function 'linux_read_loadmap':
.../src/gdb/gdbserver/linux-low.c:5284:13: error: 'struct lwp_info' has no member named 'entry'
make[1]: *** [linux-low.o] Error 1
gdb/gdbserver/
2014-04-09 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_read_loadmap): Pass current_inferior directly
to lwpid_of.
Due to a thinko, a message could be not understood and ignored. The result
was a dead-lock (gdb is waiting for an event that never happen). The port
of the thread was deallocated before new threads are discovered. As a
consequence, the origin of the message was unknown (instead of being
linked to the newly created thread).
gdb/
* darwin-nat.c (darwin_check_new_threads): Fix port leak, add
comments.
(darwin_decode_exception_message): Free port only after use.
One last time-stamp. Now none of the doc rules using move-if-change
will run unnecessarily.
* Makefile.am ($(MKDOC)): New rule, depend on chew.stamp. Move
old rule to..
(chew.stamp): ..here.
(DISTCLEANFILES): Move *.stamp..
(MOSTLYCLEANFILES): ..to here.
* Makefile.in: Regenerate.
I got tired of watching chew.c being compiled a dozen or more times
each time I do a binutils build.
* Makefile.am (MKDOC): Use $@ in command.
(aoutx.texi): New rule, depend on aoutx.stamp. Move old rule..
(aoutx.stamp): .. to here. Don't depend on chew.c, depend on MKDOC
and omit recursive MAKE. Use $< in command.
(archive.texi, archures.texi, bfdt.texi, cache.texi, coffcode.texi,
core.texi, elf.texi, elfcode.texi, mmo.texi, format.texi, libbfd.texi,
bfdio.texi, bfdwin.texi, opncls.texi, reloc.texi, section.texi,
syms.texi, targets.texi, init.texi, hash.texi, linker.texi): Similarly.
(DISTCLEANFILES): Remove *.stamp.
* Makefile.in: Regenerate.
I got the ppc476 workaround wrong. bctr (and bctrl) as the last
instruction in a page can hit the icache bug if the preceding mtctr
insn is close by, and the destination is in the first few instructions
on the next page. This scenario can occur with code generated by gcc
to implement switch statements, or in code generated to call by
function pointer.
To prevent the bctr problem it is also necessary to remove other
instructions that otherwise would be safe.
bfd/
* elf32-ppc.c (ppc_elf_relocate_section): Remove bctr from list
of safe ppc476 insns at end of page. Also remove non-branch insns.
Expand comments.
ld/
* emultempl/ppc32elf.em (no_zero_padding, ppc_finish): New functions.
(LDEMUL_FINISH): Define.
* avr-tdep.c (struct gdbarch_tdep): Mention avrxmega in the comment.
(avr_gdbarch_init): Add xmega architectures given by bfd_architecture
when setting the size of call_length.
the Cygwin and MinGW targets. The manifest is now going to be handled by gcc.
* scripttempl/pe.sc (R_RSRC): Remove default manifest.
* scripttempl/pep.sc (R_RSRC): Remove default manifest.
On mingw host, we have seen two fails as below,
p int1dim[0]^V@2
Invalid character '^V' in expression.
(gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2
p int1dim[0]^V@2^V@3
Invalid character '^V' in expression.
(gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2@3
In the test, the comment says "# Send \026@ instead of just @ in case
the kill character is @". Historically, kill character was @, and
Ctrl-V (\026) is to escape the next character. However, we don't have
to do so on mingw. This patch is to disable ctrl-v usage on mingw
hots. With this patch applied, it becomes:
p int1dim[0]@2
$607 = {0, 1}
(gdb) PASS: gdb.base/printcmds.exp: p int1dim[0]@2
p int1dim[0]@2@3
$608 = {{0, 1}, {2, 3}, {4, 5}}
Note that this patch is picked from Pierre's submission,
[RFC 6/6] Fix remaining failures in gdb.base/printcmds.exp for mingw hosts.
https://www.sourceware.org/ml/gdb-patches/2013-09/msg00943.html
gdb/testsuite:
2014-04-08 Pierre Muller <muller@sourceware.org>
* gdb.base/printcmds.exp (test_artificial_arrays): Disable
Ctrl-V use for mingw hosts.
gdb.Value.dynamic_type is supposed to work for reference and pointer
values. However, the value object in the function 'valpy_get_dynamic_type'
was being dereferenced using 'value_ind' irrespective of the value type
being TYPE_CODE_PTR or TYPE_CODE_REF. This patch fixes that to use
'coerce_ref' for TYPE_CODE_REF values.
ChangeLog:
* python/py-value.c (valpy_get_dynamic_type): Use coerce_ref to
dereference TYPE_CODE_REF values.
testsuite/
* gdb.python/py-value.c: Improve test case.
* gdb.python/py-value.exp: Add new test.
All strip operations require section headers to be present, as do most
objcopy operations. BFD is seriously confused by objects without
section info. The error message added here is similar to the error
on attempting to strip/objcopy a zero length object.
PR binutils/16811
* objcopy.c (copy_object): Error if no sections.
The testcase in pr16417 comment #6 produces a map file showing
libpthread.so.0 (write@@GLIBC_2.2.5)
ie. missing the file referencing the symbol.
* elflink.c (_bfd_elf_add_default_symbol): Pass poldbfd when
merging non-default sym.
The linker script documentation does not mention the optional comma
that may follow an output section command or an overlay command.
In some cases, where a fill expression is used, and the next
output section command begins with an operator (e.g., "/DISCARD/"),
the comma may be required to separate the two commands.
Currently, GNU ld doesn't require the comma, but gold does.
ld/
PR gold/16804
* ld.texinfo: Document optional comma following output section
command and overlay command.
bfd/
* mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out): Use target index
of output_section.
* mach-o-x86-64.c (bfd_mach_o_x86_64_swap_reloc_out): Ditto.
When aligning input sections, we are supposed to take the fill pattern
from a FILL statement, if there is one in the output section statement.
ld/
* ldlang.c (lang_size_sections_1 <lang_input_section_enum>): Use
current "fill", not "output_section_statement->fill".
ld/testsuite/
* ld-scripts/fill.d, * ld-scripts/fill.t, * ld-scripts/fill_0.s,
* ld-scripts/fill_1.s, * ld-scripts/fill_2.s: New test.
* ld-scripts/data.exp: Run it.
section before dereferencing.
(pe_print_idata, pe_print_edata, pe_print_reloc)
(rsrc_print_section): Don't bother interpreting the contents
of sections which have no contents.
long type instead of long long meant that bfd_seek (SET) could be called with a
negative offset.
PR ld/16803
* elf.c (_bfd_elf_set_section_contents): Use correct type to hold
file position.
and have it loaded by default (as long as the --target option isn't used).
PR binutils/14698
ar.c: Set plugin_target early if plugins are supported.
nm.c: Likewise.
