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.
Diagnosis of unexpected input (in this case, in an executable file)
should not crash as if it were a bug in GDB.
gdb/
PR gdb/18464
* osabi.c (generic_elf_osabi_sniff_abi_tag_sections): Use warning
rather than internal_error for an unrecognized value.
Currently access to the last pseudo register is aliased to a1. This is
done by little snippets in the beginning of xtensa_pseudo_register_read
and xtensa_pseudo_register_write that used to do such aliasing for FP
register since bdb4c075a2, but then
FP_ALIAS was expanded into gdbarch_num_regs (current_gdbarch) +
gdbarch_num_pseudo_regs (current_gdbarch) (one register past the last
pseudo register) in 304fe2552d, which
then was changed to the last pseudo register in
94a0e87711.
Drop these snippets.
2015-05-29 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* xtensa-tdep.c (xtensa_pseudo_register_read)
(xtensa_pseudo_register_write): Don't alias last pseudo register
to a1.
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
This patch fixes some intermittent test failures in
gdb.base/foll-vfork.exp where a vfork child would be (incorrectly)
resumed when handling the vfork event. In this case the result
was a subsequent event reported to the client side as a SIGTRAP
delivered to the as-yet-unknown child thread.
The new thread was resumed (incorrectly) in linux-low.c when
resume_stopped_resumed_lwps was called from
linux_wait_for_event_filtered after the vfork event had been
handled in handle_extended_wait.
Gdbserver/linux-low.c's add_thread function creates threads with
last_resume_kind == resume_continue by default. This field is
used by resume_stopped_resumed_lwps to decide whether to perform
the resume:
static void
resume_stopped_resumed_lwps (struct inferior_list_entry *entry) {
struct thread_info *thread = (struct thread_info *) entry;
struct lwp_info *lp = get_thread_lwp (thread);
if (lp->stopped
&& !lp->status_pending_p
&& thread->last_resume_kind != resume_stop
&& thread->last_status.kind == TARGET_WAITKIND_IGNORE)
{
So the fix is to make sure to set thread->last_resume_kind to
resume_stop. Here we do that for new fork children in
gdbserver/linux-low.c:handle_extended_wait.
In addition, it seemed prudent to initialize lwp_info.status_pending_p
for the new fork child. I also rearranged the initialization code
so that all of the lwp_info initialization was together, rather than
intermixed with thread_info and process_info initialization.
Tested native, native-gdbserver, native-extended-gdbserver on
x86_64 GNU/Linux.
gdb/gdbserver/
* linux-low.c (handle_extended_wait): Initialize
thread_info.last_resume_kind for new fork children.
