I read comment of scan_partial_symbols about NEED_PC and how *LOWPC
and *HIGHPC are updated:
DW_AT_ranges). If NEED_PC is set, then this function will set
*LOWPC and *HIGHPC to the lowest and highest PC values found in CU
and record the covered ranges in the addrmap.
NEED_PC is only used in the callee of scan_partial_symbols,
add_partial_subprogram,
if (pdi->tag == DW_TAG_subprogram)
{
if (pdi->has_pc_info)
{
if (pdi->lowpc < *lowpc)
*lowpc = pdi->lowpc;
if (pdi->highpc > *highpc)
*highpc = pdi->highpc;
if (need_pc)
*LOWPC and *HIGHPC is updated regardless of NEED_PC. When NEED_PC is
true, addrmap is updated. It would be clear to rename NEED_PC to
SET_ADDRMAP. That is what this patch does. Beside this, this patch
also adjust comments in related functions.
gdb:
2014-08-24 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (scan_partial_symbols): Update comments.
Rename argument 'need_pc' with 'set_addrmap'.
（add_partial_namespace): Rename argument 'need_pc' with
'set_addrmap'.
(add_partial_module): Likewise.
(add_partial_subprogram): Likewise. Update comments.
(dwarf2_name): Fix typo.
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.
The situation here is similar to that of the other nearby (previous)
sims fixed; it fails at the dv_sockser_install declaration in
sim/m32r/tconfig.in. But, as opposed to e.g. frv, this *does* have a
definition of UART_INCHAR_ADDR et al. It's somewhat tempting to keep
sim-hardware enabled here but, I'm disabling it for the same reasons
as for frv. Unsurprisingly (as m32r seems to be the template), the
same confusing lines are in sim/m32r/Makefile.in as in
sim/frv/Makefile.in at that time, deleted in 73e76d20. Again, commit
73e76d20 (for m32r as well as for frv) attempted to move the
non-existing dv-sockser.o use to $(m32r_extra_objs) but missed that
AC_SUBST would only affect @m32r_extra_objs@ and not
$(m32r_extra_objs) per se so nothing happened. As for frv, I'm
removing the $(m32r_extra_objs) too, to avoid confusion. Make
check-sim for m32r-elf shows no regressions (5 failures; 100 expected
passes) compared to bf3d9781ec (before the recent config.in regen,
after sim-hardware mostly-enabled) and eed23bb4a1 (before the
sim-hardware mostly-enabled; 2013-03-23).
sim/m32r:
* configure.ac: Default simulator hardware to off again. Remove
dead m32r_extra_objs substitution.
* configure: Regenerate.
* Makefile.in: Remove unused frv_extra_objs.
See nearby (previous) commit for the iq2000 sim; this similarly fails
at the dv_sockser_install declaration in sim/sh64/tconfig.in. I'm
disabling simulator hardware to be consistent with the state before
94c63d78f (2013-03-23) and with the actions for the frv sim and the
iq2000 sim. Make check-sim for sh64-elf shows no regressions (25
failures; 357 expected passes) compared to bf3d9781ec (before the
recent config.in regen, after sim-hardware mostly-enabled) and
eed23bb4a1 (before the sim-hardware mostly-enabled; 2013-03-23).
sim/sh64:
* configure.ac: Default simulator hardware to off again
without emitting errors when off or dv-sockser.o unavailable.
* configure: Regenerate.
See nearby (previous) commit for the frv sim; this similarly fails at
the dv_sockser_install declaration in sim/iq2000/tconfig.in. There's
no HAVE_DV_SOCKSER conditionals here and no other dv-sockser.o
artefacts so maybe there is no further fallout, but I'm going to
disable sim-hardware just be consistent with the state before
94c63d78f (2013-03-23) and with the actions for the frv sim. Make
check-sim for iq2000-elf shows no failures but that's in no small part
because it has no test-suite.
sim/iq2000:
* configure.ac: Default simulator hardware to off again
without emitting errors when off or dv-sockser.o unavailable.
* configure: Regenerate.
At 2974be626, frv-elf fails at the dv_sockser_install declaration in
sim/frv/tconfig.in. But, with the trivial #include's added (see other
sims tconfig.in, like cris or mn10300), it *still* fails building
sim/frv/devices.c because of a missing UART_INCHAR_ADDR. I have no
insight into what'd be a valid value, except that there's a definition
in m32r, which was probably used as a template with frv not finished.
Simulated hardware should not have been be enabled, and was indeed not
enabled by default before 94c63d78f (2013-03-23), where it seems to
have been enabled for no simulator-specific reason. Except
dv-sockser.o wasn't enabled even then: sim/frv/config.in wasn't
regenerated, so HAVE_DV_SOCKSER was never defined. Maybe people were
fooled by this in sim/frv/Makefile.in at that time (these two lines
were later deleted, in 73e76d20):
CONFIG_DEVICES = dv-sockser.o
CONFIG_DEVICES =
(As it seems people have missed it before: the second line overrides
the first...) I'm guessing these lines were part of the
never-completed hardware-support. Commit 73e76d20 attempted to move
the imagined dv-sockser.o from $(CONFIG_DEVICES) to $(frv_extra_objs)
but missed that AC_SUBST would only affect @frv_extra_objs@ (not
$(frv_extra_objs) per se) so nothing happened regarding sockser:
dv-sockser.o was not compiled and HAVE_DV_SOCKSER was not defined.
I'm removing the $(frv_extra_objs) too, to avoid confusion. The best
action seems to be disabling all hardware support by default again
until a specific sim maintainer finishes the work.
Make check-sim for frv-elf shows no failures after this.
sim/frv:
* configure.ac: Default simulator hardware to off again. Remove
dead frv_extra_objs substitution.
* configure: Regenerate.
* Makefile.in: Remove unused frv_extra_objs.
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.
gdb/ChangeLog:
* buildsym.h (record_line_ftype): New typedef.
(record_line): Use it.
* dwarf2read.c (dwarf_record_line, dwarf_finish_line): New functions.
(dwarf_decode_lines_1): Call them.
Only set the VLE flag if the instruction has been pulled via the VLE
instruction set. This way the flag is guaranteed to be set for VLE-only
instructions or for VLE-only processors, however it'll remain clear for
dual-mode instructions on dual-mode and, more importantly, standard-mode
processors.
gas/
* config/tc-ppc.c (md_assemble): Only set the PPC_APUINFO_VLE
flag if both the processor and opcode flags match.
ld/testsuite/
* ld-powerpc/apuinfo-vle.rd: New test.
* ld-powerpc/apuinfo-vle.s: New test source.
* ld-powerpc/apuinfo.rd: Adjust according to GAS PPC_APUINFO_VLE
handling change.
* ld-powerpc/powerpc.exp: Run the new test.
2014-08-21 Nathan Sidwell <nathan@codesourcery.com>
Maciej W. Rozycki <macro@codesourcery.com>
opcodes/
* arm-dis.c (print_arm_address): Negate the GPR-relative offset
returned if the U bit is set.
2014-08-21 Paul Brook <paul@codesourcery.com>
gas/testsuite/
* gas/arm/arch7a-mp.d: Adjust according to `print_arm_address'
offset fix.
* gas/arm/arch7r-mp.d: Likewise.
cc1: warnings being treated as errors
.../gas/config/tc-arm.c: In function 'add_to_lit_pool':
.../gas/config/tc-arm.c:3193: error: 'imm1' may be used uninitialized in this function
* config/tc-arm.c (add_to_lit_pool): Preinitialize `imm1'.
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.
When GDB uses recent version of babeltrace, such as 1.2.x, we'll see
such error emitted from babeltrace library,
(gdb) target ctf .../gdb/testsuite/gdb.trace/actions.ctf
[error] Invalid CTF stream: content size is smaller than packet headers.
[error] Stream index creation error.
[error] Open file stream error.
The problem can be reproduce out of GDB too, using babeltrace,
$ babeltrace ./fake-packet.ctf/
[error] Invalid CTF stream: content size is smaller than packet headers.
[error] Stream index creation error.
[error] Open file stream error.
Recent babeltrace library becomes more strict on CTF, and complains
about one "faked packet" GDB adds, when saving trace data in ctf
format from GDB. babeltrace 1.1.0 has a bug that it can't read trace
data smaller than a certain size (see https://bugs.lttng.org/issues/450).
We workaround it in GDB to append some meaningless data in a faked
packet to make sure trace file is large enough (see ctf.c:ctf_end).
The babeltrace issue was fixed in 1.1.1 release. However, babeltrace
recent release (since 1.1.2) starts to complain about such faked
packet. Here is a table shows that whether faked packet or no faked
packet is "supported" by various babeltrace releases,
faked packet no faked packet
1.1.0 Yes No
1.1.1 Yes Yes
1.1.2 No Yes
1.2.0 No Yes
We decide to get rid of this workaround in GDB, and people can build GDB
with libbabeltrace >= 1.1.1. In this way, both configure and ctf.c is
simpler.
Run gdb.trace/* tests in the following combinations:
wo/ this pattch 1.1.0
w/ this patch 1.1.1
w/ this patch 1.1.2
w/ this patch 1.2.0
No test results change.
gdb:
2014-08-22 Yao Qi <yao@codesourcery.com>
* ctf.c (CTF_FILE_MIN_SIZE): Remove.
(ctf_end): Remove code.
cie->output_sec is used to when merging CIEs to ensure that only CIEs
from the same output section are merged. I noticed an assignment to
this field in _bfd_elf_parse_eh_frame, and thought "That's wrong,
output_section isn't set properly when _bfd_elf_parse_eh_frame is
called from gc-sections code". It turns out that this assignment is
premature, and in fact a dead store. find_merged_cie overwrites with
the correct value before the field is ever used. On looking a little
more it becomes apparent that cie->cie_inf.u.cie.u.sec->output_section
holds the same value, so cie->output_sec is redundant.
* elf-eh-frame.c (struct cie): Delete "output_sec" field.
(cie_eq, cie_compute_hash): Use output_section from cie_inf instead.
I noticed recently that .eh_frame FDEs generated by the linker for
call stubs and .glink weren't being indexed in .eh_frame_hdr, due to
bfd_elf_discard_info being run before the linker generated .eh_frame
sections were available for parsing. This patch moves code around in
elf64-ppc.c and ppc64elf.em to avoid that problem.
Another problem fixed here is that --gc-sections parses .eh_frame
early, and the existing machinery allows only one go at parsing the
.eh_frame sections. That resulted in the linker generated .eh_frame
CIEs not being merged and no .eh_frame_hdr index entries for those
FDEs. It turns out that all the info from parsing .eh_frame is
attached to the section, so order of parsing isn't important, and
after parsing sec_info_type being set will prevent a section being
parsed again. At least, when parsing doesn't hit an error. So there
isn't really any need for "parsed_eh_frame". "merge_cies" is also
redundant, which means _bfd_elf_{begin,end}_eh_frame_parsing can also
disappear.
bfd/
* elf-bfd.h (struct eh_frame_hdr_info): Delete merge_cies and
parsed_eh_frames.
(_bfd_elf_begin_eh_frame_parsing): Delete.
(_bfd_elf_end_eh_frame_parsing): Delete.
* elf-eh-frame.c (_bfd_elf_begin_eh_frame_parsing): Delete.
(_bfd_elf_end_eh_frame_parsing): Delete.
(_bfd_elf_parse_eh_frame): Don't test parsed_eh_frame. Test
!info->relocatable in place of merge_cies.
* elflink.c (bfd_elf_gc_sections, bfd_elf_discard_info): Adjust.
* elf64-ppc.c (glink_eh_frame_cie): Pad to multiple of 8.
(ppc64_elf_size_stubs): Likewise pad stub FDE.
(ppc64_elf_build_stubs): Move code setting glink .eh_frame to..
(ppc64_elf_size_stubs): ..here and..
(ppc64_elf_finish_dynamic_sections): ..here.
ld/
* emultempl/ppc64elf.em (gld${EMULATION_NAME}_after_allocation): Call
bfd_elf_discard_info after generating glink .eh_frame. Delete
redundant test on ppc64_elf_setup_section_lists status.
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.
This TODO has been stale for over 2 years. In bd5635a1 (1991), we
already see the comment, when we only had a bare attach_command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* TODO:
* Should save/restore the tty state since it might be that the
* program to be debugged was started on this tty and it wants
* the tty in some state other than what we want. If it's running
* on another terminal or without a terminal, then saving and
* restoring the tty state is a harmless no-op.
* This only needs to be done if we are attaching to a process.
*/
/*
* attach_command --
* takes a program started up outside of gdb and ``attaches'' to it.
* This stops it cold in its tracks and allows us to start tracing it.
* For this to work, we must be able to send the process a
* signal and we must have the same effective uid as the program.
*/
void
attach_command (args, from_tty)
char *args;
int from_tty;
{
target_attach (args, from_tty);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Later in b5a3d2aa (1992) target_terminal_init, etc. calls are added to
attach_command, and in 7e97eb28 (1992) we see:
+ /* If we attached to the process, we might or might not be sharing
+ a terminal. Avoid printing error msg if we are unable to set our
+ terminal's process group to his process group ID. */
+ if (!attach_flag) {
+ OOPSY ("ioctl TIOCSPGRP");
Clearly the TODO has been stale for a long while.
I considered preserving the text elsewhere, but then thought the
comments in inflow.c already have all the necessary info.
gdb/ChangeLog:
* infcmd.c (attach_command): Remove comment.
The 48-bit LI instruction encoding has been removed from the microMIPS
ISA and no implementation ever made that included it.
* micromips-opc.c (micromips_opcodes): Remove #ifdef-ed out
48-bit "li" encoding.
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".
2014-08-21 Tony Wang <tony.wang@arm.com>
* elf32-arm.c (elf32_arm_final_link_relocate): Implement
the veneer routine for R_ARM_THM_JUMP19.
(arm_type_of_stub): Add conditional clause for R_ARM_THM_JUMP19
(elf32_arm_size_stub): Ditto.
ld/testsuite/ChangeLog
2014-08-21 Tony Wang <tony.wang@arm.com>
* ld-arm/jump-reloc-veneers-cond.s: New test.
* ld-arm/farcall-cond-thumb-arm.s: Ditto.
* ld-arm/jump-reloc-veneers-cond-short.d: Expected output
for target without a veneer generation.
* ld-arm/jump-reloc-veneers-cond-long.d: Expected output
for target with a veneer generation.
* ld-arm/farcall-cond-thumb-arm.d: Expected output for
inter working veneer generation.
* ld-arm/arm-elf.exp: Add tests for conditional branch veneer.
Recent gdb code refactor changes LONGEST from a macro to a typedef,
thus the use of it in aarch64-linux-nat.c is no longer valid.
2014-08-21 Bin Cheng <bin.cheng@arm.com>
* aarch64-linux-nat.c (dr_changed_t): Change the type from
unsigned LONGEST to ULONGEST.
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.
bfd/
PR ld/17277
* elf32-arm.c (elf32_arm_check_relocs): Increment P->pc_count for
all reloc types with pc_relative set in the howto, not just for
R_ARM_REL32 and R_ARM_REL32_NOI.
(allocate_dynrelocs_for_symbol): Update comment.
(elf32_arm_gc_sweep_hook): For all reloc types with pc_relative
set in the howto, set call_reloc_p and may_need_local_target_p but
not may_become_dynamic_p; not only for R_ARM_REL32 and R_ARM_REL32_NOI.
(elf32_arm_check_relocs): Likewise.
ld/testsuite/
PR ld/17277
* ld-arm/pcrel-shared.s: New file.
* ld-arm/pcrel-shared.rd: New file.
* ld-arm/arm-elf.exp (armelftests_common): Add it.
At the moment it is possible to configure binutils for these triples
but the resulting linker defaults to little endian with huge numbers
of testsuite failures, which on the face of it does not appear to make
much sense.
This patch makes the behaviour similar to armeb-elf and the testsuite
is clean.
bfd/ChangeLog:
2014-08-20 Will Newton <will.newton@linaro.org>
* config.bfd: Default armeb-*-eabi* to big endian.
ld/ChangeLog:
2014-08-20 Will Newton <will.newton@linaro.org>
* configure.tgt: Default armeb-*-eabi* to big endian.
addresses outside of the 32-bit range before memory exhaustion. This
results in a higher entropy implementation of ASLR when used with the
DYNAMIC_BASE flag.
* include/coff/pe.h: Add HIGH_ENTROPY_VA flag
* ld/emultempl/pep.em: Add --high-entropy-va switch
* ld/ld.texinfo: Document the --high-entropy-va switch
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.
We would like to wrap examples, output or code snippet in comments with
blank lines, and move */ to a new line if the comment is ended with the
example.
gdb:
2014-08-20 Yao Qi <yao@codesourcery.com>
* amd64-tdep.c (amd64_classify): Add a blank line after the
example. Move "*/" to a new line.
* arm-tdep.c (arm_vfp_cprc_sub_candidate): Likewise.
* arm-wince-tdep.c (arm_pe_skip_trampoline_code): Likewise.
* dwarf2read.c (psymtab_include_file_name): Likewise.
