Add --discard-none to keep all local symbols.
gold/
PR gold/17498
* object.cc (Sized_relobj_file::do_count_local_symbols): Discard
temporary locals in merge sections.
* options.cc (General_options::parse_discard_all): New method.
(General_options::parse_discard_locals): New method.
(General_options::parse_discard_none): New method.
(General_options::General_options): Initialize discard_locals_.
* options.h (--discard-all): Convert to special option.
(--discard-locals): Likewise.
(--discard-none): New option.
(General_options::discard_all): New method.
(General_options::discard_locals): New method.
(General_options::discard_sec_merge): New method.
(General_options::Discard_locals): New enum.
(General_options::discard_locals_): New data member.
This commit adds a new extended menmonic for "sync 0" (same as "sync").
The ISA documentation doesn't explicitly mention hwsync as an extended
mnemonic (yet), but it does mention "heavyweight sync" and "hwsync" as
the operation that gets performed when the sync's L field is 0.
This is only enabled for POWER4 and later.
opcodes/
* ppc-opc.c: (powerpc_opcodes) <hwsync>: New extended mnemonic.
gas/testsuite/
* gas/ppc/a2.d: Fixup test case due to new extended mnemonic.
* gas/ppc/power4.s <hwsync, lwsync, ptesync, sync>: Add tests.
* gas/ppc/power4.d: Likewise.
Patch implementing '@' GDB array operator in GCC has been rejected:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html
and so there is now a GDB tracker to implement it just in GDB:
https://sourceware.org/bugzilla/show_bug.cgi?id=18489
gdb/testsuite/ChangeLog
2015-06-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.exp (compile print *vararray@3)
(compile print *vararrayp@3): Change xfail to kfail compile/18489.
When I do something else, I find that gdbarch.c isn't sync'ed with
gdbarch.sh. This patch just move some statements on
stack_frame_destroyed_p some lines below.
gdb:
2015-06-04 Yao Qi <yao.qi@linaro.org>
* gdbarch.c: Regenerate it.
Gold undercounts the number of program headers it's going to add when
initially evaluating the SIZEOF_HEADERS expression. As a result, scripts
that use it end up skipping a page unnecessarily when the starting address
is too low. The undercounting is because it doesn't count the PT_INTERP
segment.
Then, when finalizing symbols, gold overcounts the program headers: all
segments have already been created, but we still count the headers we
expected to add from the script.
This patch fixes both problems.
gold/
* script-sections.cc (Script_sections::Script_sections): Initialize
segments_created_.
(Script_sections::create_note_and_tls_segments): Set flag when
segments are created.
(Script_sections::expected_segment_count): Count PT_INTERP.
(Script_sections::attach_sections_using_phdrs_clause): Set flag when
segments are created.
* script-sections.h (Script_sections::segments_created_): New data
member.
In PR 15370, it is noted that gold does not distinguish between
"*(.foo .bar)" and "*(.foo) *(.bar)" in linker scripts. In both
cases, gold groups all .foo sections together, followed by all
.bar sections, whereas in the first case, it should collect all
.foo and .bar sections in the order seen.
If you add sort specs, the Gnu linker has some bizarre corner
cases that I do not try to replicate. In particular,
"*(SORT_BY_NAME(.foo) SORT_BY_NAME(.bar))" does the same thing
as "*(.foo) *(.bar)". But if you apply a sort spec
to just one of several patterns, say, "*(SORT_BY_NAME(.foo) .bar)",
the Gnu linker will collect any .bar section it sees before the
first .foo, then all .foo sections, then all remaining .bar
sections. With this patch, if any of the input patterns have a
sort spec, gold will group them all as it did before; e.g.,
all .foo sections followed by all .bar sections.
2015-06-03 Cary Coutant <ccoutant@gmail.com>
gold/
PR gold/15370
* script-sections.cc
(Output_section_element_input::set_section_addresses): When there
are several patterns with no sort spec, put all sections in the same
bin.
* testsuite/Makefile.am (script_test_12): New testcase.
(script_test_12i): New testcase.
* testsuite/Makefile.in: Regenerate.
* testsuite/script_test_12.t: New test linker script.
* testsuite/script_test_12i.t: New test linker script.
* testsuite/script_test_12a.c: New test source file.
* testsuite/script_test_12b.c: New test source file.
Currently inferior memory is allocated by inferior mmap() but it is never
deallocated; despite the injected objfile incl. its symbols is freed. This was
intentional so that one can do for example:
inferior:
char *str = "foo";
GDB:
(gdb) compile code str = "bar";
I believe later patches will be needed to introduce full control over keeping
vs. discarding the injected module as being discussed in:
compile: objfiles lifetime UI
https://sourceware.org/ml/gdb/2015-04/msg00051.html
Message-ID: <20150429135735.GA16974@host1.jankratochvil.net>
https://sourceware.org/ml/gdb/2015-05/msg00007.html
As decided by Phil it is better not to leak inferior pages as users can
workaround the issue above for example by:
(gdb) compile code str = strdup ("bar");
I have checked that in fact gdb/doc/ (written by Phil) already expects the
injected code will be unmapped so that does not need to be changed:
compile code int ff = 5; p = &ff;
In this example, @code{p} would point to @code{ff} when the
@code{compile} command is executing the source code provided to it.
However, as variables in the (example) program persist with their
assigned values, the variable @code{p} would point to an invalid
location when the command exists.
gdb/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* arch-utils.c (default_infcall_munmap): New.
* arch-utils.h (default_infcall_munmap): New declaration.
* compile/compile-object-load.c (struct munmap_list, munmap_list_add)
(munmap_list_free, munmap_listp_free_cleanup): New.
(struct setup_sections_data): Add field munmap_list_headp.
(setup_sections): Call munmap_list_add.
(compile_object_load): New variable munmap_list_head, initialize
setup_sections_data.munmap_list_headp, return munmap_list_head.
* compile/compile-object-load.h (struct munmap_list): New declaration.
(struct compile_module): Add field munmap_list_head.
(munmap_list_free): New declaration.
* compile/compile-object-run.c (struct do_module_cleanup): Add field
munmap_list_head.
(do_module_cleanup): Call munmap_list_free.
(compile_object_run): Pass munmap_list_head to do_module_cleanup.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (infcall_munmap): New.
* linux-tdep.c (linux_infcall_munmap): New.
(linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (keep jit in memory): Rename to ...
(do not keep jit in memory): ... this.
(expect 5): Change it to ...
(expect no 5): ... this.
When commit the following code for Matthew, I wrongly included my local changes. Revert it. Sorry.
commit a5932920ef
Author: Matthew Wahab <matthew.wahab@arm.com>
Date: Wed Jun 3 10:03:50 2015 +0100
I sent a patch in 2013 for this (incorrectly named =thread-created):
https://cygwin.com/ml/gdb-patches/2013-06/msg00129.html
Tom Tromey was ok with the change, but suggested to add a test as well.
Then I forgot about this patch until today. So here it is again, with the
corresponding test.
The problem is that the =thread-exited event does not appear when detaching
from a local process. It does appear with remote though. It's not a really
big deal, but I'd like it to be consistent.
Tested with local and remote Linux on my Ubuntu 14.04.
gdb/ChangeLog:
PR gdb/15564
* inferior.c (detach_inferior): Call exit_inferior_1 with silent = 0.
gdb/testsuite/ChangeLog:
PR gdb/15564
* gdb.mi/mi-detach.exp: New file.
When --build-id=tree is selected, gold would schedule a set of
tasks to run to compute md5 hashes in parallel on chunks of the
file. The scheduling was done before the
Write_after_input_sections_task ran, so if we are compressing
debug sections, the output file will change size and be remapped
to a new address, sometimes causing the build id computation to
crash, but even when it doesn't crash, it wouldn't include the
debug information in the hash computation.
This patch delays the scheduling of the md5 tasks until after
Write_after_input_sections_task.
gold/
PR gold/17819
* gold.cc (queue_final_tasks): When --build-id=tree, queue a
separate task to schedule the build id computation.
* layout.cc (Hash_task::Hash_task): Remove build_id_blocker,
add Output_file and offset.
(Hash_task::run): Get and release the input views.
(Hash_task::is_runnable): Always return NULL (always runnable).
(Layout::queue_build_id_tasks): Remove.
(Layout::write_build_id): Add array_of_hashes and size_of_hashes
parameters; use them instead of class members.
(Build_id_task_runner::run): New function.
(Close_task_runner::run): Pass array_of_hashes and size_of_hashes
to write_build_id.
* layout.h (Layout::queue_build_id_tasks): Remove.
(Layout::write_build_id): Add array_of_hashes and size_of_hashes
parameters.
(Layout::array_of_hashes_): Remove.
(Layout::size_of_array_of_hashes_): Remove.
(Layout::input_view_): Remove.
(Build_id_task_runner): New class.
(Close_task_runner::Close_task_runner): Add array_of_hashes and
size_of_hashes parameters.
(Close_task_runner::array_of_hashes_): New data member.
(Close_task_runner::size_of_hashes_): New data member.
* testsuite/Makefile.am
(flagstest_compress_debug_sections_and_build_id_tree): New test.
* testsuite/Makefile.in: Regenerate.
The ARMv8.1 architecture introduced the Privileged Access Never extension. This
adds a processor state field PSTATE.PAN which can be accessed using the MRS/MSR
instructions.
This patch adds support for the PAN architecture feature and processor state
field to libopcode.
include/opcode
2015-06-01 Matthew Wahab <matthew.wahab@arm.com>
* aarch64.h (AARCH64_FEATURE_PAN): New.
(aarch64_sys_reg_supported_p): Declare.
(aarch64_pstatefield_supported_p): Declare.
opcodes/
2015-06-01 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-opc.c (F_ARCHEXT): New.
(aarch64_sys_regs): Add "pan".
(aarch64_sys_reg_supported_p): New.
(aarch64_pstatefields): Add "pan".
(aarch64_pstatefield_supported_p): New.
Initially there is some chain (let's say the longest one
but that doe snot matter). Consequently its elements from the middle are
being removed and there remains only some few unambiguous top and bottom ones.
The original idea why the comparison should be sharp ("<") was that if there
are multiple chains like (0xaddr show jmp instruction address):
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
then - such situation cannot exist - if two jmp instructions in "a" have the
same address they must also jump to the same address (*).
(*) jump to a computed address would be never considered for the DWARF
tail-call records.
So there could be:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
But then "a" frame itself is ambiguous and it must not be displayed.
I did not realize that there can be self-tail-call:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
which intersects to:
main(0x100) -> <???>? -> a(0x200) -> d(0x400)
And so if the first chain was chosen the
main(0x100) -> a(0x200) -> d(0x400)
then the final intersection has callers+callees==length.
> for example, if CALLERS is 3 and
> CALLEES is 2, what does the chain look like?
main(0x100) -> x(0x150) -> y(0x200) -> <???>? -> a(0x200) -> d(0x400)
And if LENGTH is 7 then:
call_site[0] = main(0x100)
call_site[1] = x(0x150)
call_site[2] = y(0x200)
call_site[3] = garbage
call_site[4] = garbage
call_site[5] = a(0x200)
call_site[6] = d(0x400)
gdb/ChangeLog
2015-06-01 Andreas Schwab <schwab@linux-m68k.org>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* dwarf2-frame-tailcall.c (pretended_chain_levels): Correct
assertion.
* dwarf2loc.c (chain_candidate): Likewise.
gdb/testsuite/ChangeLog
2015-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* gdb.arch/amd64-tailcall-self.S: New file.
* gdb.arch/amd64-tailcall-self.c: New file.
* gdb.arch/amd64-tailcall-self.exp: New file.
This patch is to use PTRACE_{G,S}ETREGSET to fetch and store VFP
registers if kernel supports.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_vfp_regs): Use PTRACE_GETREGSET.
(store_vfp_regs): Use PTRACE_SETREGSET.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store FP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_fpregister): Use PTRACE_GETREGSET.
(fetch_fpregs): Likewise.
* arm-linux-nat.c (store_fpregister): Use PTRACE_SETREGSET.
(store_fpregs): Likewise.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store GP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_register): Use PTRACE_GETREGSET.
(fetch_regs): Likewise.
(store_regs): Use PTRACE_SETREGSET.
(store_register): Likewise.
I'll let arm-linux-nat.c to use PTRACE_GETREGSET if kernel supports,
so this patch is to move have_ptrace_getregset from x86-linux-nat.c
to linux-nat.c.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* x86-linux-nat.c (have_ptrace_getregset): Move it to ...
* linux-nat.c: ... here.
* x86-linux-nat.h (have_ptrace_getregset): Move the declaration
to ...
* linux-nat.h: ... here.
Macros PTRACE_GETREGSET and PTRACE_SETREGSET are defined locally in
some places in GDB and GDBserver. This patch is to move them to
nat/linux-ptrace.h to avoid duplication.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* amd64-linux-nat.c: Include "nat/linux-ptrace.h".
* i386-linux-nat.c: Likewise.
* nat/linux-ptrace.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Define.
* s390-linux-nat.c: Include "nat/linux-ptrace.h".
(PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* x86-linux-nat.c: Include "nat/linux-ptrace.h".
* x86-linux-nat.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
gdb/gdbserver:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* linux-s390-low.c (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* linux-x86-low.c: Likewise.
BFD_RELOC_AARCH64_TLSLE_ADD_LO12 is used to generate simplest
one-instruction addressing for TLS LE model when tls size is smaller
4K. Linker need to make sure there is no TLS offset overflow.
2015-06-01 Jiong Wang <jiong.wang@arm.com>
bfd/
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Set overflow type to
complain_overflow_unsigned for BFD_RELOC_AARCH64_TLSLE_ADD_LO12.
* elfxx-aarch64.c (_bfd_aarch64_elf_resolve_relocation): Don't use
PGOFF for BFD_RELOC_AARCH64_TLSLE_ADD_LO12, that will mask off all
potential high overflowed bits.
ld/testsuite/
* ld-aarch64/tprel_add_lo12_overflow.s: New testcase.
* ld-aarch64/tprel_add_lo12_overflow.d: Nex expectation file.
* ld-aarch64/aarch64-elf.exp: Run new testcase.
As pointed out before, the documentation mandates the rounding mode to
follow the GPR, so disassembler should produce output accordingly.
gas/testsuite/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512f.s: Adjust operand order for Intel syntax
vcvt{,u}si2ss.
* gas/i386/x86-64-avx512f.s: Adjust operand order for Intel
syntax vcvt{,u}si2s{d,s}.
opcodes/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* i386-dis.c (print_insn): Swap rounding mode specifier and
general purpose register in Intel mode.
As pointed out before, the documentation mandates the rounding mode to
follow the GPR, so gas should accept such input. As the brojen code got
released already we sadly will need to continue to also accept the
badly ordered operands.
gas/testsuite/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512f-intel.d: Adjust expectations on operand order.
* gas/i386/evex-lig256-intel.d: Likewise.
* gas/i386/evex-lig512-intel.d: Likewise.
* gas/i386/x86-64-avx512f-intel.d: Likewise.
* gas/i386/x86-64-evex-lig256-intel.d: Likewise.
* gas/i386/x86-64-evex-lig512-intel.d: Likewise.
opcodes/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* i386-opc.tbl: New IntelSyntax entries for vcvt{,u}si2s{d,s}.
* i386-tbl.h: Regenerate.
gdb/
* go32-nat.c (go32_xfer_memory): Fix the return value to be
compatible to what read_child and write_child return. This
unbreaks that DJGPP build of GDB which was broken since v7.7.
