Commit dd7e64d45b may optimize out
i386/x86-64 JUMP_SLOT relocation. If there is no JUMP_SLOT relocation
left, we don't need to the first .plt entry. This patch allocates
space for the first .plt entry only if we also reserve space for a PLT
slot for JUMP_SLOT relocation.
bfd/
* elf32-i386.c (elf_i386_allocate_dynrelocs): Allocate space
for the first .plt entry only if needed.
* elf64-x86-64.c (elf_x86_64_allocate_dynrelocs): Likewise.
ld/testsuite/
* ld-i386/i386.exp: Run pltgot-1 for Linux targets.
* ld-x86-64/x86-64.exp: Likewise.
* ld-i386/pltgot-1.d: New file.
* ld-i386/pltgot-1.s: Likewise.
* ld-x86-64/pltgot-1.d: Likewise.
* ld-x86-64/pltgot-1.s: Likewise.
This patch contains the accumulated documentation changes for the
rest of the extended-remote follow fork patchset.
gdb/ChangeLog:
* NEWS: Announce fork support in the RSP and support
for fork debugging in extended mode.
gdb/doc/ChangeLog:
* gdb.texinfo (Forks): Note that fork debugging is
supported in extended mode.
(Remote Configuration): Add fork event features to table
of packet settings.
(Stop Reply Packets): Add fork events to list of stop reasons.
(General Query Packets): Add fork events to tables of
'gdbfeatures' and 'stub features' supported in the qSupported
packet, as well as to the list containing stub feature
details.
This patch implements catchpoints for fork events on extended-remote
Linux targets.
Implementation appeared to be straightforward, requiring four new functions
in remote.c to implement insert/remove of fork/vfork catchpoints. These
functions are essentially stubs that just return 0 ('success') if the
required features are enabled. If the fork events are being reported, then
catchpoints are set and hit.
However, there are some extra issues that arise with catchpoints.
1) Thread creation reporting -- fork catchpoints are hit before the
follow_fork has been completed. When stopped at a fork catchpoint
in the native implementation, the new process is not 'reported'
until after the follow is done. It doesn't show up in the inferiors
list or the threads list. However, in the gdbserver case, an
'info threads' while stopped at a fork catchpoint will retrieve the
new thread info from the target and add it to GDB's data structures,
prior to the follow operations. Because of this premature report,
things on the GDB side eventually get very confused.
So in remote.c:remote_update_thread_list, we check to see if there
are any pending fork parent threads. If there are we remove the
related fork child thread from the thread list sent by the target.
2) Kill process before fork is followed -- on the native side in
linux-nat.c:linux_nat_kill, there is some code to handle the case where
a fork has occurred but follow_fork hasn't been called yet. It does
this by using the last status to determine if a follow is pending, and
if it is, to kill the child task. The use of last_status is fragile
in situations like non-stop mode where other events may have occurred
after the fork event. This patch identifies a fork parent
in remote.c:extended_remote_kill in a way similar to that used in
thread creation reporting above. If one is found, it kills the new
child as well.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote. Tested the
case of killing the forking process before the fork has been followed
manually.
gdb/ChangeLog:
* remote.c (remote_insert_fork_catchpoint): New function.
(remote_remove_fork_catchpoint): New function.
(remote_insert_vfork_catchpoint): New function.
(remote_remove_vfork_catchpoint): New function.
(pending_fork_parent_callback): New function.
(remove_new_fork_child): New function.
(remote_update_thread_list): Call remote_notif_get_pending_events
and remove_new_fork_child.
(extended_remote_kill): Kill fork child when killing the
parent before follow_fork completes.
(init_extended_remote_ops): Initialize target vector with
new fork catchpoint functions.
This patch implements follow-fork for vfork on extended-remote Linux targets.
The implementation follows the native implementation as much as possible.
Most of the work is done on the GDB side in the existing code now in
infrun.c. GDBserver just has to report the events and do a little
bookkeeping.
Implementation includes:
* enabling VFORK events by adding ptrace options for VFORK and VFORK_DONE
to linux-low.c:linux_low_ptrace_options.
* handling VFORK and VFORK_DONE events in linux-low.c:handle_extended_wait
and reporting them to GDB.
* including VFORK and VFORK_DONE events in the predicate
linux-low.c:extended_event_reported.
* adding support for VFORK and VFORK_DONE events in RSP by adding stop
reasons "vfork" and "vforkdone" to the 'T' Stop Reply Packet in both
gdbserver/remote-utils.c and gdb/remote.c.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Handle PTRACE_EVENT_FORK and
PTRACE_EVENT_VFORK_DONE.
(linux_low_ptrace_options, extended_event_reported): Add vfork
events.
* remote-utils.c (prepare_resume_reply): New stop reasons "vfork"
and "vforkdone" for RSP 'T' Stop Reply Packet.
* server.h (report_vfork_events): Declare
global variable.
gdb/ChangeLog:
* remote.c (remove_vfork_event_p): New function.
(remote_follow_fork): Add vfork event type to event checking.
(remote_parse_stop_reply): New stop reasons "vfork" and
"vforkdone" for RSP 'T' Stop Reply Packet.
This patch implements the architecture-specific pieces of follow-fork
for remote and extended-remote Linux targets, which in the current
implementation copyies the parent's debug register state into the new
child's data structures. This is required for x86, arm, aarch64, and
mips.
This follows the native implementation as closely as possible by
implementing a new linux_target_ops function 'new_fork', which is
analogous to 'linux_nat_new_fork' in linux-nat.c. In gdbserver, the debug
registers are stored in the process list, instead of an
architecture-specific list, so the function arguments are process_info
pointers instead of an lwp_info and a pid as in the native implementation.
In the MIPS implementation the debug register mirror is stored differently
from x86, ARM, and aarch64, so instead of doing a simple structure assignment
I had to clone the list of watchpoint structures.
Tested using gdb.threads/watchpoint-fork.exp on x86, and ran manual tests
on a MIPS board and an ARM board. Aarch64 hasn't been tested.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_linux_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
* linux-arm-low.c (arm_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
* linux-low.c (handle_extended_wait): Call new target function
new_fork.
* linux-low.h (struct linux_target_ops) <new_fork>: New member.
* linux-mips-low.c (mips_add_watchpoint): New function
extracted from mips_insert_point.
(the_low_target) <new_fork>: Initialize new member.
(mips_linux_new_fork): New function.
(mips_insert_point): Call mips_add_watchpoint.
* linux-x86-low.c (x86_linux_new_fork): New function.
(the_low_target) <new_fork>: Initialize new member.
This patch implements basic support for follow-fork and detach-on-fork on
extended-remote Linux targets. Only 'fork' is supported in this patch;
'vfork' support is added n a subsequent patch. This patch depends on
the previous patches in the patch series.
Sufficient extended-remote functionality has been implemented here to pass
gdb.base/multi-forks.exp, as well as gdb.base/foll-fork.exp with the
catchpoint tests commented out. Some other fork tests fail with this
patch because it doesn't provide the architecture support needed for
watchpoint inheritance or fork catchpoints.
The implementation follows the same general structure as for the native
implementation as much as possible.
This implementation includes:
* enabling fork events in linux-low.c in initialize_low and
linux_enable_extended_features
* handling fork events in gdbserver/linux-low.c:handle_extended_wait
- when a fork event occurs in gdbserver, we must do the full creation
of the new process, thread, lwp, and breakpoint lists. This is
required whether or not the new child is destined to be
detached-on-fork, because GDB will make target calls that require all
the structures. In particular we need the breakpoint lists in order
to remove the breakpoints from a detaching child. If we are not
detaching the child we will need all these structures anyway.
- as part of this event handling we store the target_waitstatus in a new
member of the parent lwp_info structure, 'waitstatus'. This
is used to store extended event information for reporting to GDB.
- handle_extended_wait is given a return value, denoting whether the
handled event should be reported to GDB. Previously it had only
handled clone events, which were never reported.
* using a new predicate in gdbserver to control handling of the fork event
(and eventually all extended events) in linux_wait_1. The predicate,
extended_event_reported, checks a target_waitstatus.kind for an
extended ptrace event.
* implementing a new RSP 'T' Stop Reply Packet stop reason: "fork", in
gdbserver/remote-utils.c and remote.c.
* implementing new target and RSP support for target_follow_fork with
target extended-remote. (The RSP components were actually defined in
patch 1, but they see their first use here).
- remote target routine remote_follow_fork, which just sends the 'D;pid'
detach packet to detach the new fork child cleanly. We can't just
call target_detach because the data structures for the forked child
have not been allocated on the host side.
Tested on x64 Ubuntu Lucid, native, remote, extended-remote.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Implement return value,
rename argument 'event_child' to 'event_lwp', handle
PTRACE_EVENT_FORK, call internal_error for unrecognized event.
(linux_low_ptrace_options): New function.
(linux_low_filter_event): Call linux_low_ptrace_options,
use different argument fo linux_enable_event_reporting,
use return value from handle_extended_wait.
(extended_event_reported): New function.
(linux_wait_1): Call extended_event_reported and set
status to report fork events.
(linux_write_memory): Add pid to debug message.
(reset_lwp_ptrace_options_callback): New function.
(linux_handle_new_gdb_connection): New function.
(linux_target_ops): Initialize new structure member.
* linux-low.h (struct lwp_info) <waitstatus>: New member.
* lynx-low.c: Initialize new structure member.
* remote-utils.c (prepare_resume_reply): Implement stop reason
"fork" for "T" stop message.
* server.c (handle_query): Call handle_new_gdb_connection.
* server.h (report_fork_events): Declare global flag.
* target.h (struct target_ops) <handle_new_gdb_connection>:
New member.
(target_handle_new_gdb_connection): New macro.
* win32-low.c: Initialize new structure member.
gdb/ChangeLog:
* linux-nat.c (linux_nat_ptrace_options): New function.
(linux_init_ptrace, wait_lwp, linux_nat_filter_event):
Call linux_nat_ptrace_options and use different argument to
linux_enable_event_reporting.
(_initialize_linux_nat): Delete call to
linux_ptrace_set_additional_flags.
* nat/linux-ptrace.c (current_ptrace_options): Rename to
supported_ptrace_options.
(additional_flags): Delete variable.
(linux_check_ptrace_features): Use supported_ptrace_options.
(linux_test_for_tracesysgood, linux_test_for_tracefork):
Likewise, and remove additional_flags check.
(linux_enable_event_reporting): Change 'attached' argument to
'options'. Use supported_ptrace_options.
(ptrace_supports_feature): Change comment. Use
supported_ptrace_options.
(linux_ptrace_set_additional_flags): Delete function.
* nat/linux-ptrace.h (linux_ptrace_set_additional_flags):
Delete function prototype.
* remote.c (remote_fork_event_p): New function.
(remote_detach_pid): New function.
(remote_detach_1): Call remote_detach_pid, don't mourn inferior
if doing detach-on-fork.
(remote_follow_fork): New function.
(remote_parse_stop_reply): Handle new "T" stop reason "fork".
(remote_pid_to_str): Print "process" strings for pid/0/0 ptids.
(init_extended_remote_ops): Initialize to_follow_fork.
This patch implements gdbserver routines to clone the breakpoint lists of a
process, duplicating them for another process. In gdbserver, each process
maintains its own independent breakpoint list. When a fork call creates a
child, all of the breakpoints currently inserted in the parent process are
also inserted in the child process, but there is nothing to describe them
in the data structures related to the child. The child must have a
breakpoint list describing them so that they can be removed (if detaching)
or recognized (if following). Implementation is a mechanical process of
just cloning the lists in several new functions in gdbserver/mem-break.c.
Tested by building, since none of the new functions are called yet. This
was tested with another patch in the series that implements follow-fork.
gdb/gdbserver/ChangeLog:
* mem-break.c (APPEND_TO_LIST): Define macro.
(clone_agent_expr): New function.
(clone_one_breakpoint): New function.
(clone_all_breakpoints): New function.
* mem-break.h: Declare new functions.
This patch implements a mechanism for GDB to determine whether fork
events are supported in gdbserver. This is a preparatory patch for
remote fork and exec event support.
Two new RSP packets are defined to represent fork and vfork event
support. These packets are used just like PACKET_multiprocess_feature
to denote whether the corresponding event is supported. GDB sends
fork-events+ and vfork-events+ to gdbserver to inquire about fork
event support. If the response enables these packets, then GDB
knows that gdbserver supports the corresponding events and will
enable them.
Target functions used to query for support are included along with
each new packet.
In order for gdbserver to know whether the events are supported at the
point where the qSupported packet arrives, the code in nat/linux-ptrace.c
had to be reorganized. Previously it would test for fork/exec event
support, then enable the events using the pid of the inferior. When the
qSupported packet arrives there may not be an inferior. So the mechanism
was split into two parts: a function that checks whether the events are
supported, called when gdbserver starts up, and another that enables the
events when the inferior stops for the first time.
Another gdbserver change was to add some global variables similar to
multi_process, one per new packet. These are used to control whether
the corresponding fork events are enabled. If GDB does not inquire
about the event support in the qSupported packet, then gdbserver will
not set these "report the event" flags. If the flags are not set, the
events are ignored like they were in the past. Thus, gdbserver will
never send fork event notification to an older GDB that doesn't
recognize fork events.
Tested on Ubuntu x64, native/remote/extended-remote, and as part of
subsequent patches in the series.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_supports_fork_events): New function.
(linux_supports_vfork_events): New function.
(linux_target_ops): Initialize new structure members.
(initialize_low): Call linux_check_ptrace_features.
* lynx-low.c (lynx_target_ops): Initialize new structure
members.
* server.c (report_fork_events, report_vfork_events):
New global flags.
(handle_query): Add new features to qSupported packet and
response.
(captured_main): Initialize new global variables.
* target.h (struct target_ops) <supports_fork_events>:
New member.
<supports_vfork_events>: New member.
(target_supports_fork_events): New macro.
(target_supports_vfork_events): New macro.
* win32-low.c (win32_target_ops): Initialize new structure
members.
gdb/ChangeLog:
* nat/linux-ptrace.c (linux_check_ptrace_features): Change
from static to extern.
* nat/linux-ptrace.h (linux_check_ptrace_features): Declare.
* remote.c (anonymous enum): <PACKET_fork_event_feature,
* PACKET_vfork_event_feature>: New enumeration constants.
(remote_protocol_features): Add table entries for new packets.
(remote_query_supported): Add new feature queries to qSupported
packet.
(_initialize_remote): Exempt new packets from the requirement
to have 'set remote' commands.
This commit allows GDB to determine filenames of main executables
when debugging using remote stubs without multiprocess extensions.
The qXfer:exec-file:read packet is extended to allow an empty
annex, with the meaning that the remote stub should supply the
filename of whatever it thinks is the current process.
gdb/ChangeLog:
* remote.c (remote_add_inferior): Call exec_file_locate_attach
for fake PIDs as well as real ones.
(remote_pid_to_exec_file): Send empty annex if PID is fake.
gdb/doc/ChangeLog:
* gdb.texinfo (General Query Packets): Document
qXfer:exec-file:read with empty annex.
gdb/gdbserver/ChangeLog:
* server.c (handle_qxfer_exec_file): Use current process
if annex is empty.
Disp16 and Disp32 aren't supported by direct branches in 64-bit mode.
This patch removes them from 64-bit direct branches.
* opcodes/i386-opc.tbl (call): Remove Disp16|Disp32 from 64-bit
direct branch.
(jmp): Likewise.
* i386-tbl.h: Regenerated.
Mixing target and not-target directives can be used to run for x86_64-*-*
target while skipping x86_64-*-gnux32 target. This patch allows mixing
target and not-target directives. It is used to skip elfedit-1 for
x86_64-*-gnux32.
* binutils-all/elfedit-1.d: Skip x86_64-*-gnux32.
* lib/utils-lib.exp (run_dump_test): Allow mixing target and
not-target directives.
This patch sets the default ELF output format of assembler and linker to
EM_IAMCU when binutils is configured to i?86-*-elfiamcu target.
gas/
* configure.tgt (arch): Set to iamcu for i386-*-elfiamcu target.
* config/tc-i386.c (i386_mach): Support iamcu.
(i386_target_format): Likewise.
ld/
* configure.tgt: Support i[3-7]86-*-elfiamcu target.
ld/testsuite/
* ld-i386/i386.exp (iamcu_tests): Run iamcu-4.
* ld-i386/iamcu-4.d: New file.
binutils/
* elfedit.c (enum elfclass): New.
(input_elf_class): Change type to enum elfclass.
(output_elf_class): New.
(elf_class): Change return type to enum elfclass. Support EM_386
and EM_IAMCU.
(update_elf_header): Check if input and output ELF classes match.
(elf_machine): Support EM_386 and EM_IAMCU.
(main): Update input_elf_class. Set output_elf_class.
* doc/binutils.texi: Update elfedit.
binutils/testsuite/
* binutils-all/elfedit-5.d: New file.
* binutils-all/elfedit.exp: Run elfedit-5.
The first argument to bfd_get_8/bfd_put_8 isn't used. But we should
use something real. Replace input_bfd and output_bfd with abfd.
* elf32-i386.c (elf_i386_convert_mov_to_lea): Replace input_bfd
and output_bfd with abfd.
* elf64-x86-64.c (elf_x86_64_convert_mov_to_lea): Likewise.
2015-05-08 Yao Qi <yao@codesourcery.com>
Sandra Loosemore <sandra@codesourcery.com>
gdb/
* dwarf2read.c (setup_type_unit_groups): Do NULL pointer check
to 'lh->include_dirs' before accessing to it.
(psymtab_include_file_name): Likewise.
(dwarf_decode_lines_1): Likewise.
(dwarf_decode_lines): Likewise.
(file_file_name): Likewise.
2015-05-08 Sandra Loosemore <sandra@codesourcery.com>
gdb/gdbserver/
* linux-nios2-low.c: Include elf/common.h. Adjust comments.
Remove HAVE_PTRACE_GETREGS conditionals.
(nios2_regsets): Use PTRACE_GETREGSET and PTRACE_SETREGSET
instead of PTRACE_GETREGS and PTRACE_SETREGS.
2015-05-08 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_breakpoint_from_pc): Revert to using
"trap 31" as the breakpoint instruction on all targets.
In my last commit to make gdb.base/coredump-filter.exp be more robust
regarding using arrays in the global namespace, I cleared the
"coredump_var_addr" array like this:
set coredump_var_addr ""
# use coredump_var_addr as an array...
This causes DejaGNU to complain because the variable is first set as
non-array, and the used as an array. The correct way to do this is to
unset the variable using:
unset -nocomplain coredump_var_addr
# use coredump_var_addr as an array...
The "-nocomplain" part is necessary because if the variable doesn't
exist "unset" will not error.
Tested on Fedora 20 x86_64.
gdb/testsuite/ChangeLog:
2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Correctly unset
"coredump_var_addr" array.
Attempting to build libiberty on LynxOS-178 fails trying to compile
mkstemps.c with the following error:
mkstemps.c:84:18: error: storage size of 'tv' isn't known
struct timeval tv;
^
This file would normally include <sys/time.h> to get the type's
definition, but unfortunately LynxOS-178 does not want us to use
<sys/time.h>, only <time.h>. The configure script correctly finds
this out and generates a config.h file where HAVE_SYS_TIME_H is
undefined:
/* Define to 1 if you have the <sys/time.h> header file. */
/* #undef HAVE_SYS_TIME_H */
This patch fixes the build issue by falling back on including <time.h>
if <sys/time.h> could not be included (and provided that HAVE_TIME_H
is defined, of course).
libiberty/ChangeLog:
* mkstemps.c: #include <time.h> if HAVE_TIME_H is defined
but not HAVE_SYS_TIME_H.
Sequential test runs are stopping prematurely like this:
$ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp"
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ...
can not find channel named "exp6"
while executing
"match_max [match_max -d]"
(procedure "default_gdb_init" line 26)
invoked from within
"default_gdb_init $test_file_name"
(procedure "gdb_init" line 83)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 18)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
...
make[2]: *** [check-single] Error 1
make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make: *** [check] Error 2
default_gdb_init has this:
# Unlike most tests, we have a small number of tests that generate
# a very large amount of output. We therefore increase the expect
# buffer size to be able to contain the entire test output. This
# is especially needed by gdb.base/info-macros.exp.
match_max -d 65536
# Also set this value for the currently running GDB.
match_max [match_max -d]
It's the second match_max that is erroring. As that call does not
specify an explicit channel name with -i, expect defaults to
$spawn_id, which is pointing at a channel that is already gone. (If
the spawn_id variable is not set, match_max defaults to
$user_spawn_id / stdin/out).
gdb/testsuite/ChangeLog:
2015-05-08 Pedro Alves <palves@redhat.com>
* gdb.server/non-existing-program.exp: Unset spawn_id.
PR gas/18347
* config/tc-arm.h (TC_EQUAL_IN_INSN): Define.
* config/tc-arm.c (arm_tc_equal_in_insn): New function. Move
the symbol name checking code to here from...
(md_undefined_symbo): ... here.
Consider the following declarations...
type Obj_T (Selected_Flights_Length : Natural) is
record
Selected_Flights : Flights.List.T (1 .. Selected_Flights_Length);
end record;
Broken : Obj_T;
... which defines a variable named "broken" which is a discrimated
record where broken.Selected_Flights is an array whose upper bound
is stored in the record's Selected_Flights_Length component.
Trying to print the value of that object currently fails:
(gdb) print broken
cannot find reference address for offset property
Looking at the debugging info, we see that variable "Broken" is
a reference...
<1><8e3>: Abbrev Number: 21 (DW_TAG_const_type)
<8e4> DW_AT_type : <0x8e8>
<1><8e8>: Abbrev Number: 22 (DW_TAG_reference_type)
<8e9> DW_AT_byte_size : 8
<8ea> DW_AT_type : <0x7ec>
... to ...
<1><7ec>: Abbrev Number: 12 (DW_TAG_structure_type)
<7ed> DW_AT_name : (indirect string, offset: 0xc6d): reprod__obj_t
<7f1> DW_AT_decl_file : 2
<7f2> DW_AT_decl_line : 15
<7f3> DW_AT_GNAT_descriptive_type: <0x87e>
<7f7> DW_AT_sibling : <0x87e>
... which has 2 members, the first one being the discriminant...
<2><7fb>: Abbrev Number: 9 (DW_TAG_member)
<7fc> DW_AT_name : (indirect string, offset: 0xc98): selected_flights_length
<800> DW_AT_decl_file : 2
<801> DW_AT_decl_line : 15
<802> DW_AT_type : <0x807>
<806> DW_AT_data_member_location: 0
... and the second one being the one that causes trouble...
<2><83d>: Abbrev Number: 9 (DW_TAG_member)
<83e> DW_AT_name : (indirect string, offset: 0xd17): selected_flights
<842> DW_AT_decl_file : 2
<843> DW_AT_decl_line : 17
<844> DW_AT_type : <0x815>
<848> DW_AT_data_member_location: 4
The second field's type is an array....
<2><815>: Abbrev Number: 14 (DW_TAG_array_type)
<816> DW_AT_name : (indirect string, offset: 0xd2f): reprod__obj_t__T5sP
<81a> DW_AT_GNAT_descriptive_type: <0x7e1>
<81e> DW_AT_type : <0x748>
<822> DW_AT_sibling : <0x830>
... whose uppper bound is a reference to <0x7fb>...
<3><826>: Abbrev Number: 15 (DW_TAG_subrange_type)
<827> DW_AT_type : <0x830>
<82b> DW_AT_upper_bound : <0x7fb>
<3><82f>: Abbrev Number: 0
Because the upper bound is dynamic, we try to resolve it.
As it happens, the upper-bound resolution for this range type
works fine. What breaks is when we try to resolve this range
type's target type, which is:
<2><830>: Abbrev Number: 16 (DW_TAG_subrange_type)
<831> DW_AT_upper_bound : <0x7fb>
<835> DW_AT_name : (indirect string, offset: 0xc7b): reprod__obj_t__T4s___XDLU_1__selected_flights_length
<839> DW_AT_type : <0x766>
<83d> DW_AT_artificial : 1
It is actually pretty much the same as the first subrange type,
so you might ask why this is causing trouble, when the resolution
of the previous DIE worked like a charm???
Well, for that, we need to backtrack a bit, and notice that, ahead
of the DW_TAG_structure_type's DIE, there is the following DIE:
<1><7e1>: Abbrev Number: 6 (DW_TAG_typedef)
<7e2> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s
<7e6> DW_AT_decl_file : 2
<7e7> DW_AT_decl_line : 17
<7e8> DW_AT_type : <0x849>
... and that DIE references an array type...
<2><849>: Abbrev Number: 14 (DW_TAG_array_type)
<84a> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s
<84e> DW_AT_GNAT_descriptive_type: <0x864>
<852> DW_AT_type : <0x748>
<856> DW_AT_sibling : <0x864>
... whose subrange is...
<3><85a>: Abbrev Number: 15 (DW_TAG_subrange_type)
<85b> DW_AT_type : <0x830>
<85f> DW_AT_upper_bound : <0x7fb>
... where the subrange's base type is the DW_TAG_subrange_type DIE
that is causing problem.
In summary, we process the typedef first, which causes us to process
the second subrange BEFORE we process the struct DIE itself, and
therefore the struct's discriminent (DW_TAG_member #1). As a result,
while trying to handle the reference to that DW_TAG_member #1 as
the upper bound of the second range type, we do...
case DW_AT_data_member_location:
{
[...]
baton->referenced_type = get_die_type (target_die->parent,
target_cu);
... where target_die->parent (DW_TAG_member #1) hasn't been processed
yet, and thus get_die_type returns NULL.
This is what later causes us problems trying to find the right address
to use as the base address for our field, which then triggers the
error message we are seeing.
This patch fixes the issue by calling read_type_die instead of
get_die_type. If the DIE has already been processed, then this
is the same as get_die_type. If not, the it'll get the parent
die to be read, and then get its type.
gdb/ChangeLog:
* dwarf2read.c (attr_to_dynamic_prop)
<DW_AT_data_member_location>: Use read_type_die isntead of
get_die_type.
Tested on x86_64-linux, no regression.
No testcase, unfortunately, as the reproducer was given to us by
a customer, and it's been otherwise surprisingly difficult to
reproduce the same error outside of that reproducer.
We observed on x86-windows that trying to call a function from
GDB leads to a mysterious "Invalid cast" error. This can be
observed in gdb.ada/float_param.exp:
(gdb) call set_long_double(1, global_small_struct, 4.0)
Invalid cast.
This happens because the 3rd parameter, a Long_Long_Float, is
actually passed wrapped inside a PAD structure. As documented
in GNAT's exp_dbug.ads, PAD types are simple wrappers that GNAT
uses to handle types with size or alignment constraints.
We already support those when printing an object encapsulated
in a PAD type, but not when trying to pass an argument that
is wrapped inside a PAD type. As a result, what happens is that
call_function_by_hand ends up with an argument with a type
that looks incompatible with the expected type of the argument.
The error comes when trying to push the arguments in inferior
memory, while trying to coerce each one of them to their expected
types (in value_arg_coerce).
Note that the problem is not specific to Windows, but so far, this is
the only platform where we've seen this happen.
gdb/ChangeLog:
* ada-lang.c (ada_convert_actual): Add handling of formals
passed inside an aligner type.
Tested on x86-windows (AdaCore testsuite) and x86_64-linux (official
testsuite as well as AdaCore's testsuite).
Now that the erc32 files have been updated to contain an FSF copyright
header, these files should no longer be in the exclude list.
gdb/ChangeLog:
* copyright.py (NOT_FSF_LIST): Remove sim/erc32 entries.
On ELF target, the assembler normally generates code which can go into a
shared library where non-weak symbols can be preempted. The -mno-shared
option tells the assembler to generate code not for a shared library,
where non-weak symbols won't be preempted. The resulting code is slightly
smaller. This option mainly affects the handling of branch instructions.
gas/
* config/tc-i386.c (no_shared): New.
(OPTION_MNO_SHARED): Likewise.
(elf_symbol_resolved_in_segment_p): Check no_shared.
(md_longopts): Add mno-shared.
(md_parse_option): Handle OPTION_MNO_SHARED.
(md_show_usage): Add -mno-shared.
* doc/c-i386.texi: Document -mno-shared.
gas/testsuite/
* gas/i386/i386.exp: Run relax-4 and x86-64-relax-3.
* gas/i386/relax-4.d: New file.
* gas/i386/x86-64-relax-3.d: Likewise.
Hi,
We see some fails in gdb.base/coredump-filter.exp when we do remote
gdbserver testing, like what I did for arm/aarch64 linux testing or
run it with board file remote-gdbserver-on-localhost
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp'
we find that this line in the test doesn't work as expected,
remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
although such pattern has been used in gdb testsuite somewhere else,
but the special thing here is that we redirect the output to
/proc/$ipid/coredump_filter on the remote target. DejaGNU will
redirect the output from the remote target to local, and looks tcl
gets confused by these two redirection.
After trying pass different parameters to remote_exec and hacking
remote_exec/rsh_exec/local_exec, I got no success, I decide
to give up, and try to update /proc/$ipid/coredump_filter by the c
code directly.
This patch adds a c function set_coredump_filter to update
coredump_filter, and GDB calls it.
gdb/testsuite:
2015-05-08 Yao Qi <yao.qi@linaro.org>
PR gdb/18208
* gdb.base/coredump-filter.c (set_coredump_filter): New function.
* gdb.base/coredump-filter.exp (do_save_core): Call inferior
function set_coredump_filter, and remove remote_exec call.
Remove argument ipid. Callers update.
(top level): Don't get inferior's PID.
GDBserver steps over breakpoint if the condition is false, but if target
doesn't support hardware single step, the step over is very simple, if
not incorrect, in linux-arm-low.c:
/* We only place breakpoints in empty marker functions, and thread locking
is outside of the function. So rather than importing software single-step,
we can just run until exit. */
static CORE_ADDR
arm_reinsert_addr (void)
{
struct regcache *regcache = get_thread_regcache (current_thread, 1);
unsigned long pc;
collect_register_by_name (regcache, "lr", &pc);
return pc;
}
and linux-mips-low.c does the same. GDBserver sets a breakpoint at the
return address of the current function, resume and wait the program hits
the breakpoint in order to achieve "breakpoint step over". What if
program hits other user breakponits during this "step over"?
It is worse if the arm/thumb interworking is considered. Nowadays,
GDBserver arm backend unconditionally inserts arm breakpoint,
/* Define an ARM-mode breakpoint; we only set breakpoints in the C
library, which is most likely to be ARM. If the kernel supports
clone events, we will never insert a breakpoint, so even a Thumb
C library will work; so will mixing EABI/non-EABI gdbserver and
application. */
(const unsigned char *) &arm_breakpoint,
(const unsigned char *) &arm_eabi_breakpoint,
note that the comments are no longer valid as C library can be compiled
in thumb mode.
When GDBserver steps over a breakpoint in arm mode function, which
returns to thumb mode, GDBserver will insert arm mode breakpoint by
mistake and the program will crash. GDBserver alone is unable to
determine the arm/thumb mode given a PC address. See how GDB does
it in arm-tdep.c:arm_pc_is_thumb.
After thinking about how to teach GDBserver inserting right breakpoint
(arm or thumb) for a while, I reconsider it from a different direction
that it may be unreasonable to run target-side conditional breakpoint for
targets without hardware single step. Pedro also pointed this out here
https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html
This patch is to add a new target_ops hook
supports_conditional_breakpoints, and only reply
";ConditionalBreakpoints+" if it is true. On linux targets,
supports_conditional_breakpoints returns true if target has hardware
single step, on other targets, (win32, lynx, nto, spu), set it to NULL,
because conditional breakpoint is a linux-specific feature.
gdb/gdbserver:
2015-05-08 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_supports_conditional_breakpoints): New
function.
(linux_target_ops): Install new target method.
* lynx-low.c (lynx_target_ops): Install NULL hook for
supports_conditional_breakpoints.
* nto-low.c (nto_target_ops): Likewise.
* spu-low.c (spu_target_ops): Likewise.
* win32-low.c (win32_target_ops): Likewise.
* server.c (handle_query): Check
target_supports_conditional_breakpoints.
* target.h (struct target_ops) <supports_conditional_breakpoints>:
New field.
(target_supports_conditional_breakpoints): New macro.
