When GDB finds out the target triggered a watchpoint, and the target
has non-continuable watchpoints, GDB sets things up to step past the
instruction that triggered the watchpoint. This is just like stepping
past a breakpoint, but goes through a different mechanism - it resumes
only the thread that needs to step past the watchpoint, but also
switches a "infwait state" global, that has the effect that the next
target_wait only wait for events only from that thread.
This forcing of a ptid to pass to target_wait obviously becomes a
bottleneck if we ever support stepping past different watchpoints
simultaneously (in separate processes).
It's also unnecessary -- the target should only return events for
threads that have been resumed; if no other thread than the one we're
stepping past the watchpoint has been resumed, then those other
threads should not report events. If we couldn't assume that, then
stepping past regular breakpoints would be broken for not likewise
forcing a similar infwait_state.
So this patch eliminates infwait_state, and instead teaches keep_going
to mark step_over_info in a way that has the breakpoints module skip
inserting watchpoints (because we're stepping past one), like it skips
breakpoints when we're stepping past one.
Tested on:
- x86_64 Fedora 20 (continuable watchpoints)
- PPC64 Fedora 18 (non-steppable watchpoints)
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (should_be_inserted): Don't insert watchpoints if
trying to step past a non-steppable watchpoint.
* gdbthread.h (struct thread_info) <stepping_over_watchpoint>: New
field.
* infrun.c (struct step_over_info): Add new field
'nonsteppable_watchpoint_p' and adjust comments.
(set_step_over_info): New 'nonsteppable_watchpoint_p' parameter.
Adjust.
(clear_step_over_info): Clear nonsteppable_watchpoint_p as well.
(stepping_past_nonsteppable_watchpoint): New function.
(step_over_info_valid_p): Also return true if stepping past a
nonsteppable watchpoint.
(proceed): Adjust call to set_step_over_info. Remove reference to
init_infwait_state.
(init_wait_for_inferior): Remove reference to init_infwait_state.
(waiton_ptid): Delete global.
(struct execution_control_state)
<stepped_after_stopped_by_watchpoint>: Delete field.
(wait_for_inferior, fetch_inferior_event): Always pass
minus_one_ptid to target_wait.
(init_thread_stepping_state): Clear 'stepping_over_watchpoint'
field.
(init_infwait_state): Delete function.
(handle_inferior_event): Remove infwait_state handling.
(handle_signal_stop) <watchpoints handling>: Adjust after
stepped_after_stopped_by_watchpoint removal. Don't remove
breakpoints here nor set infwait_state. Set the thread's
stepping_over_watchpoint flag, and call keep_going instead.
(keep_going): Handle stepping_over_watchpoint. Adjust
set_step_over_info calls.
* infrun.h (stepping_past_nonsteppable_watchpoint): Declare
function.
... instead of trap_expected.
Gets rid of one singlestep_breakpoints_inserted_p reference, and is
generally more to the point.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (step_over_info_valid_p): New function.
(resume): Use step_over_info_valid_p instead of checking the
threads's trap_expected flag.
Don't use debug_reg_state for both:
* "intent" - what we want the debug registers to look like
* "reality" - what/which were the contents of the DR registers when
the event triggered
Reserve it for the former only, like in the GNU/Linux port.
Otherwise the core x86 debug registers code can get confused if the
inferior itself changes the debug registers since GDB last set them.
This is also a requirement for being able to set watchpoints while the
target is running, if/when we get to it on Windows. See the big
comment in x86_dr_stopped_data_address.
Seems to me this may also fixes propagating watchpoints to all threads
-- continue_one_thread only calls win32_set_thread_context (what
copies the DR registers to the thread), if something already fetched
the thread's context before. Something else may be masking this
issue, I haven't checked.
Smoke tested by running gdbserver under Wine, connecting to it from
GNU/Linux, and checking that I could trigger a watchpoint as expected.
Joel tested it on x86-windows using AdaCore's testsuite.
gdb/gdbserver/
2014-10-15 Pedro Alves <palves@redhat.com>
PR server/17487
* win32-arm-low.c (arm_set_thread_context): Remove current_event
parameter.
(arm_set_thread_context): Delete.
(the_low_target): Adjust.
* win32-i386-low.c (debug_registers_changed)
(debug_registers_used): Delete.
(update_debug_registers_callback): New function.
(x86_dr_low_set_addr, x86_dr_low_set_control): Mark all threads as
needing to update their debug registers.
(win32_get_current_dr): New function.
(x86_dr_low_get_addr, x86_dr_low_get_control)
(x86_dr_low_get_status): Fetch the debug register from the thread
record's context.
(i386_initial_stuff): Adjust.
(i386_get_thread_context): Remove current_event parameter. Don't
clear debug_registers_changed nor copy DR values to
debug_reg_state.
(i386_set_thread_context): Delete.
(i386_prepare_to_resume): New function.
(i386_thread_added): Mark the thread as needing to update irs
debug registers.
(the_low_target): Remove i386_set_thread_context and install
i386_prepare_to_resume.
* win32-low.c (win32_get_thread_context): Adjust.
(win32_set_thread_context): Use SetThreadContext
directly.
(win32_prepare_to_resume): New function.
(win32_require_context): New function, factored out from ...
(thread_rec): ... this.
(continue_one_thread): Call win32_prepare_to_resume on each thread
we're about to continue.
(win32_resume): Call win32_prepare_to_resume on the event thread.
* win32-low.h (struct win32_thread_info)
<debug_registers_changed>: New field.
(struct win32_target_ops): Change prototype of set_thread_context,
delete set_thread_context and add prepare_to_resume.
(win32_require_context): New declaration.
gdb/ChangeLog:
* python/lib/gdb/__init__.py (packages): Add "printer".
* python/lib/gdb/command/bound_registers.py: Moved to ...
* python/lib/gdb/printer/bound_registers.py: ... here.
Add printer to global set of builtin printers. Rename printer from
"bound" to "mpx_bound128".
* python/lib/gdb/printing.py (_builtin_pretty_printers): New global,
registered as global "builtin" printer.
(add_builtin_pretty_printer): New function.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Update, and add
gdb/printer/__init__.py.
On 32-bit S390 targets the longjmp target address "naturally" has the
most significant bit set. That bit indicates the addressing mode and
is not part of the address itself. Thus, in analogy with similar
cases (like when computing the caller PC in
insert_step_resume_breakpoint_at_caller), this change removes
non-address bits from the longjmp target address before using it as a
breakpoint address.
Note that there are two ways for determining the longjmp target
address: via a probe or via a gdbarch method. This change only
affects the probe method, because it is assumed that the address
returned by the gdbarch method is usable as-is.
This change was tested together with a patch that enables longjmp
probes in glibc for S/390:
https://sourceware.org/ml/libc-alpha/2014-10/msg00277.html
gdb/ChangeLog:
* gdb/infrun.c (process_event_stop_test): Apply
gdbarch_addr_bits_remove to longjmp resume address.
This file:
- Isn't used by GDBserver currently.
- Isn't included in the WHICH list in features/Makefile, so hasn't
been regenerated to pick the latest microblaze or generic fixes.
Just delete it.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* regformats/microblaze.dat: Delete file.
The Microblaze PC register is called "rpc", not "pc", as can be seen
in microblaze-core.xml. Fix this, so GDBserver can find the register in
the regcache.
gdb/
2014-10-15 Ajit Agarwal <ajitkum@xilinx.com>
* features/Makefile (microblaze-expedite): Replace pc with rpc.
* regformats/microblaze-with-stack-protect.dat: Regenerate.
Before this, a copy constructor declared as in the following snippet was
not being treated as a copy constructor.
class A
{
public:
A (A &); // OK.
A (const A &); // Not being treated as a copy constructor because of the
// 'const' qualifier.
};
gdb/ChangeLog:
PR c++/13403
PR c++/15154
* gnu-v3-abi.c (gnuv3_pass_by_reference): Lookup copy constructors
with qualified args.
Test gdb.python/py-parameter.exp expects output "$srcdir/$subdir:\$cdir:\$cwd",
but proc gdb_reinitialize_dir doesn't set $srcdir/$subdir in search
directories on remote host because it doesn't exist on remote host.
proc gdb_reinitialize_dir { subdir } {
global gdb_prompt
if [is_remote host] {
return ""
}
It causes the fail below:
(gdb) python print (gdb.parameter ('directories'))^M
/tmp/gdb:$cdir:$cwd^M
(gdb) FAIL: gdb.python/py-parameter.exp: python print (gdb.parameter ('directories'))
This patch is to fix this fail by not matching $srcdir/$subdir on remote host.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on
remote host.
I see the following fails in the remote host testing we do for mingw32
hosted GDB,
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line current locationn filename
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line python.c:26 filename
The test cases doesn't consider remote host and assumes that directory
on build also exists on host. In this patch, we only match file base
name if host is remote, otherwise, match file with dir name.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Match file base name if host is
remote, otherwise match file name with dir name.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Likewise.
This patch is to clean up various gdb.python/*.exp tests, such as
removing trailing ".*" from the pattern and fix one typo I find during
reading the code.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Remove trailing ".*". Fix typo
locationn.
* gdb.python/py-symbol.exp: Remove trailing ".*" in the
pattern.
* gdb.python/py-symtab.exp: Likewise.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
This patch is a response to what I commented on:
<https://sourceware.org/ml/gdb-patches/2014-10/msg00046.html>
When reviewing Jose's USDT probe support patches. Basically, in his
patch he had to create dummy functions for the set_semaphore and the
clear_semaphore methods of probe_ops (gdb/probe.h), because those
functions were called inconditionally from inside gdb/breakpoint.c and
gdb/tracepoint.c. However, the semaphore concept may not apply to all
types of probes, and this is the case here: USDT probes do not have
semaphores (although SDT probes do).
Anyway, this is a simple (almost obvious) patch to guard the call to
{set,clear}_semaphore. It does not introduce any regression on a
Fedora 20 x86_64.
I will apply it in a few days in case there is no comment.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* breakpoint.c (bkpt_probe_insert_location): Call set_semaphore
only if it is not NULL.
(bkpt_probe_remove_location): Likewise, for clear_semaphore.
* probe.h (struct probe_ops) <set_semaphore>: Update comment.
(struct probe_ops) <clear_semaphore>: Likewise.
* tracepoint.c (start_tracing): Call set_semaphore only if it is
not NULL.
(stop_tracing): Likewise, for clear_semaphore.
Joel contacted me offlist with a question about a warning that one of
his customers was seeing. The message came from the new
linker-debugger interface, which uses SDT probes internally. The
warning said:
(gdb) run
[...]
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Argument to arithmetic operation not a number or boolean.
This should not have happened in the environment the customer was
using (RHEL-6.x), so I found it strange. Another thing caught my
attention: the last message, saying "Argument to arithmetic operation
not a number or boolean.".
Joel kindly investigated the issue further, and found the answer for
this. To quote him:
(gdb) set lang c
(gdb) p 48+$ebp
$4 = (void *) 0xffffd0f8
So far so good. But...
(gdb) set lang ada
(gdb) p 48+$ebp
Argument to arithmetic operation not a number or boolean.
Ooops! Interestingly, if you revert the order of the operands...
(gdb) p $ebp+48
$5 = (access void) 0xffffd0f8
So the problem is doing pointer arithmetics when the language is set
to Ada.
I remembered that, during the parsing and the evaluation of SDT probe
arguments, the code sets the language as current_language, because, at
that time, I thought it was not necessary to worry about the language
given that the code implements its own parser. I was wrong. So here
is a patch to fix that, by setting the language as C, which should
guarantee that the maths are done in the right way (TM).
It was somewhat hard to find a reproducer for this issue. In the end,
what I had to do was to create a testcase that used the %ebp register
on some displacement (e.g., "-4(%ebp)"), which finally triggered the
bug. I am not sure why I could not trigger it when using other
registers, but I did not want to spend too much time investigating
this issue, which seemed like an Ada issue. Also, because of this
peculiar way to trigger the problem, the testcase only covers x86-like
targets (i.e., i*86 and x86_64 with -m32).
Joel kindly tested this for me, and it worked. I also ran a full
regression test here on my Fedora 20 x86_64, and everything is fine.
I will push this patch in a few days if there are no comments.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_argument): Initialize expout explicitly
using language_c, instead of current_language.
gdb/testsuite/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
Hi,
I see the following fails on arm-none-eabi target,
-var-list-children --simple-values struct_declarations ^M
^done,numchild="11",children=[...,child={name="struct_declarations.func_ptr_struct",exp="func_ptr_struct",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl (*)(int, char *, long)",thread-id="1"},child={name="struct_declarations.func_ptr_ptr",exp="func_ptr_ptr",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl *(*)(int, char *, long)",thread-id="1"},...
(gdb) ^M
FAIL: gdb.mi/mi-var-child.exp: listing of children, simple types: names, type and values, complex types: names and types
-var-set-format weird.func_ptr_ptr natural^M
^done,format="natural",value="0x0 <_ftext>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr in natural
In the test, "0x0" is expected, but "0x0 <_ftext>" is in the output.
Function pointers point to address zero, and tests assume there is no
symbol on address zero. However, on my arm-none-eabi target, there is
a code symbol _ftext on address zero, and test fails. Note that "set
print symbol off" doesn't take effect for function pointer.
int (*f) (void);
f = main;
(gdb) p f
$1 = (int (*)(void)) 0x8048400 <main>
(gdb) set print symbol off
(gdb) p f
$2 = (int (*)(void)) 0x8048400 <main>
In order to erase the difference, we can assign some function address
explicitly to function pointer, so the test behaves in a unique way.
In this patch, we assign nothing1 and nothing2 to function pointers
func_ptr_struct and func_ptr_ptr respectively, and update test as the
source file is changed.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-child.exp: Step over new added statements.
Update test to match the new output.
* gdb.mi/var-cmd.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-display.exp: Update test to match output.
Step to the line specified by $line_dct_nothing.
Increase the number of lines to step.
Hi,
I modify mi-var-child.exp and find that the pattern to match the output
of -var-update * is quite complicated. However, it can be simplified by
using mi_varobj_update. That is what this patch does.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.exp: Use mi_varobj_update to simplify
tests.
* gdb.mi/mi2-var-child.exp: Likewise.
This test will pass if the CU is the first CU in the binary.
If libc debugging info is installed it may not be, in which case
the CU offset values are wrong.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset
from the start of the CU.
gdb/ChangeLog:
* py-objfile.c (objfpy_initialize): New function.
(objfpy_new, objfile_to_objfile_object): Call it.
* py-progspace.c (pspy_initialize): New function.
(pspy_new, pspace_to_pspace_object): Call it.
gdb/ChangeLog
2014-10-13 Miroslav Franc <mfranc@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "catch" command.
* break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing
newline.
gdb/testsuite/ChangeLog
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
But IMO it is a functionality regression as:
* gdb_test_sequence permits arbitary number of lines of text between those
lines being matched. Former regex string did not allow it.
This may make a difference if GDB regresses by printing some unexpected
line after the breakpoint info line (like a "silent" line).
> * \[\r\n\]+ can be used to anchor the beginning of the pattern, in the sense
> of Perl regex ^ /m match. At least I have found such cases in existing
> *.exp files so I used that. Using ^ really does not work.
>
> But I am not aware how to do Perl regex $ /m match. Using $ really does
> not work. But this means that for example the trailing
> ( \\((host|target) evals\\))?
> on the line
> "\[\r\n\]+\[ \t\]+stop only if i == 1( \\((host|target) evals\\))?"
> originally made sense there but now it can be removed as it has no longer
> any functionality there - it will match now any trailing line garbage.
by Yao Qi:
In this test case, ( \\((host|target) evals\\))? isn't needed in the
pattern. What we test here is to save breakpoints into file and restore
them from file. The contents saved in file are:
break save-bp.c:31
condition $bpnum i == 1
the information about the place where the condition is evaluated isn't
saved, so we don't need to check. Breakpoint save and restore has
nothing to do with where the condition is evaluated (host or target). I
am fine to leave it here now.
gdb/testsuite/ChangeLog
2014-10-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/save-bp.exp (info break): Use gdb_test_sequence.
Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection. However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.
tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus
qTStatus is disabled after receiving the empty reply during connecting
to the remote target. When the test executes command "tstatus" again,
remote_get_trace_status returns -1 at the very beginning, and no RSP
packet is sent out.
This patch is to enable qTStatus packet again.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Execute command
"set remote trace-status-packet on" before "tstatus".
Hi,
We see the following fail in the real remote testing...
(gdb) Executing on target: kill -9 29808 (timeout = 300)
spawn [open ...]^M
sh: 1: kill: No such process
The test tries to kill gdbserver in this way:
set server_pid [exp_pid -i [board_info target fileid]]
remote_exec target "kill -9 $server_pid"
in native testing, we'll get the pid of spawned gdbserver, however, in
remote testing, we'll get the pid of ssh session, since we start
gdbserver on the remote target through ssh. The pid on build doesn't
exist on target.
In this patch, we tweak server-kill.c to get the parent pid, which is
the pid of GDBserver. GDB gets it and kill GDBserver on target.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
(main): Call getppid.
* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
and continue to it. Read variable "server_pid".
This patch is to remove some lines which looks unnecessary. These
lines were added when server-kill.exp was added. In the version 1,
https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test
calls runto_main and delete breakpoint on main,
+if ![runto_main] {
+ return -1
+}
+
+# Otherwise the breakpoint at 'main' would not cause insert
breakpoints during
+# first step.
+delete_breakpoints
However, in the version 2
https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main
is removed but delete_breakpoints is still there. AFAICS, the line of
delete_breakpoints can be removed too.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Remove "delete_breakpoints".
As the result of the patch below, GDB updates thread list when a stop is
presented to user. The tests don't have to fetch thread list explicitly.
[PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html
This patch is to remove the test code updating thread list.
Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.threads/thread-find.exp: Don't execute command
"info threads".
* gdb.threads/attach-into-signal.exp (corefunc): Likewise.
* gdb.threads/linux-dp.exp: Don't check the condition
$threads_created equals to zero.
This does most of the mechanical removal. IOW, the easy part.
This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.
mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c. Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.
I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration mips-sgi-irix6 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
make: *** [all] Error 2
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
(HFILES_NO_SRCDIR): Remove solib-irix.h.
* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
and been removed.
* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
* configure.ac: Remove references to IRIX.
* configure.host: Add *-*-irix* to the obsolete hosts section.
Remove all other references to irix.
* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
Delete files.
gdb/testsuite/
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
We currently validate the target description, but then forget to
reject it if found invalid.
Tested that incorrect descriptions are rejected and GDB warns about
them.
Tested the Microblaze Design with and without stack-protect registers.
The gdb command "info registers" displayed the register correctly. If
a stack protect design is not selected, only core registers are
displayed. When the stack-protect registers are selected in the
design, the core registers along with stack-protect registers are
displayed.
gdb/
2014-10-10 Ajit Agarwal <ajitkum@xilinx.com>
* microblaze-tdep.c (microblaze_gdbarch_init): If the description
isn't valid, release the tdesc arch data and return NULL.
We're now doing a vsyscall/vDSO address range lookup whenever we fetch
shared libraries, either through an explicit "info shared", or when
the target reports new libraries have been loaded, in order to filter
out the vDSO from glibc's DSO list. Before we started doing that, GDB
would only ever lookup the vsyscall's address range once in the
process's lifetime.
Looking up the vDSO address range requires an auxv lookup (which is
already cached, so no problem), but also reading the process's
mappings from /proc to find out the vDSO's mapping's size. That
generates extra RSP traffic when remote debugging. Particularly
annoying when the process's mappings grow linearly as more libraries
are mapped in, and we went through the trouble of making incremental
DSO list updates work against gdbserver (when the probes-based dynamic
linker interface is available).
The vsyscall/vDSO is mapped by the kernel when the process is
initially mapped in, and doesn't change throughout the process's
lifetime, so we can cache its address range.
Caching at this level brings GDB back to one and only one vsyscall
address range lookup per process.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* linux-tdep.c: Include observer.h.
(linux_inferior_data): New global.
(struct linux_info): New structure.
(invalidate_linux_cache_inf, linux_inferior_data_cleanup)
(get_linux_inferior_data): New functions.
(linux_vsyscall_range): Rename to ...
(linux_vsyscall_range_raw): ... this.
(linux_vsyscall_range): New function; handles caching.
(_initialize_linux_tdep): Register linux_inferior_data. Install
inferior_exit and inferior_appeared observers.
With upstream glibc, GDB prints:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
A bug's been filed for glibc a few years back:
http://sourceware.org/bugzilla/show_bug.cgi?id=13097
but it's still not resolved. It's not clear whether there's even
consensus that this is indeed a glibc bug. It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:
- the vDSO is mapped by the kernel, not userspace, therefore we
should load its symbols right from the process's start of life,
even before glibc / the userspace loader sets up the initial DSO
list. The program might even be using a custom loader or no
loader.
- that kind of hints at that solib.c should handle retrieving shared
library lists from more than one source, and that symfile-mem.c's
loading of the vDSO would be converted to load and relocate the
vDSO's bfd behind the target_so_ops interface.
- and then, once glibc links in the vDSO to its DSO list, we'd need
to either:
a) somehow hand over the vDSO from one target_so_ops to the other
b) simply keep hiding glibc's entry.
And then b) seems the simplest.
With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.
We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* solib-svr4.c (svr4_read_so_list): Rename to ...
(svr4_current_sos_1): ... this and change the function comment.
(svr4_current_sos): New function.
gdb/testsuite/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
We have a case in solib-svr4.c where we could reuse symfile-mem.c's
vDSO range lookup. Since symfile-mem.c is not present in all
configurations solib-svr4.c is, move that lookup to a gdbarch hook.
This has the minor (good) side effect that we stop even trying the
target_auxv_search lookup against targets that don't have a concept of
a vDSO, in case symfile-mem.c happens to be linked in the build
(--enable-targets=all).
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_vsyscall_range): New function.
* arch-utils.h (default_vsyscall_range): New declaration.
* gdbarch.sh (vsyscall_range): New hook.
* gdbarch.h, gdbarch.c: Regenerate.
* linux-tdep.c (linux_vsyscall_range): New function.
(linux_init_abi): Install linux_vsyscall_range as
vsyscall_range gdbarch hook.
* memrange.c (address_in_mem_range): New function.
* memrange.h (address_in_mem_range): New declaration.
* symfile-mem.c (find_vdso_size): Delete function.
(add_vsyscall_page): Use gdbarch_vsyscall_range.
This patch fixes the bug described in PR tdep/9390, which is about a
wrong check in the following code:
...
/* optional copying of args in r2-r7 to r10-r13. */
/* Probably only in optimized case but legal action for prologue. */
else if ((inst & 0xff00) == 0x4600 /* 46SD mov rD, rS */
&& (inst & 0x00f0) >= 0x0020 && (inst & 0x00f0) <= 0x0070
&& (inst & 0x000f) >= 0x00a0 && (inst & 0x000f) <= 0x000d)
^^^^^^^^^^^^^^^^^^^^^^^^^
...
This condition will never trigger, and the fix proposed in the bug
(which made sense to me) was to test against 0x000a. I tried finding
documentation about this target, but couldn't find anything. I don't
even know if it is still used, but decided to submit the fix anyway.
Tested on my x86_64 Fedora 20 GNU/Linux.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/9390
* xstorxstormy16-tdep.c (xstormy16_analyze_prologue): Fix possible
typo when using logical AND to determine instruction type.
As a result of commit b57bacec, local variable 'printed' is no longer
used. This patch is to remove it.
gdb:
2014-10-09 Yao Qi <yao@codesourcery.com>
* infrun.c (handle_signal_stop): Remove local variable 'printed'.
This commit makes fbsd-tdep.c not include string.h or gdb_assert.h
as both are already included by defs.h.
gdb/ChangeLog:
* fbsd-tdep.c: Do not include string.h or gdb_assert.h.
This commit includes common-exceptions.h in common-defs.h and removes
all other inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include common-exceptions.h.
* exceptions.h: Do not include common-exceptions.h.
gdb/gdbserver/ChangeLog:
* server.h: Do not include common-exceptions.h.
This commit includes cleanups.h in common-defs.h and removes all other
inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include cleanups.h.
* common/common-exceptions.c: Do not include cleanups.h.
* utils.h: Likewise.
gdb/gdbserver/ChangeLog:
* server.h: Do not include cleanups.h.
A helper function called `add_offset_16' is used by
`extended_mips16_next_pc' to calculate branch destinations. Weirdly
enough the helper does not do what the name suggests and rather than
doing its work for a 16-bit immediate branch offset it makes its
calculations on a 26-bit immediate target used by JAL and JALX
instructions. Furthermore the JAL/JALX calculation is only needed once
by `extended_mips16_next_pc' while a 16-bit branch offset calculation
is made inline several times across `extended_mips16_next_pc'.
This change therefore replaces the contents of `add_offset_16' with the
16-bit branch offset calculation and updates `extended_mips16_next_pc'
accordingly.
* mips-tdep.c (add_offset_16): Rewrite to implement what the
name implies.
(extended_mips16_next_pc): Update accordingly.
This change addresses a regression in gdb.dwarf2/dw2-skip-prologue.exp
across MIPS16 multilibs:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
Breakpoint 1 at 0x400721
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint 1 address previously adjusted from 0x00400725 to
0x00400721.
Breakpoint 1, 0x00400721 in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
warning: GDB can't find the start of the function at 0x4006dd.
GDB is unable to find the start of the function at 0x4006dd
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006dd for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
Program received signal SIGBUS, Bus error.
0x0040072b in main ()
(gdb) FAIL: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- notice the breakpoint adjustment messages that are already a bad
sign. These happen when a breakpoint is requested in a branch delay
slot and are not supposed to happen unless explicitly requested with an
address pointing to a branch delay slot instruction. No symbol or line
debug information is supposed to direct GDB to place a breakpoint in a
delay slot.
Here's how `main' looks like:
00400718 <main>:
400718: 64f5 save 40,ra,s0-s1
40071a: 1a00 01a8 jal 4006a0 <func>
40071e: 0104 addiu s1,sp,16
400720: 1a00 01b7 jal 4006dc <func+0x3c>
400724: 6702 move s0,v0
400726: e049 addu v0,s0,v0
400728: 65b9 move sp,s1
40072a: 6473 restore 24,ra,s0-s1
40072c: e8a0 jrc ra
40072e: 6500 nop
-- so 0x400725 is the MIPS16 instruction address of the first MOVE
instruction seen above, in a delay slot of the preceding JAL instruction
indeed. This test case arranges for `main' to have no debug information
so it is one of the heuristic prologue scanners, `mips16_scan_prologue'
specifically in this case, that is responsible for finding the right
location for the breakpoint to place.
In this case the prologue really ends with the ADDIU instruction,
reordered into the delay slot of the first JAL instruction. Of course
we can't place the breakpoint for `main' after it as by doing so we'll
let `func' to be called before hitting this breakpoint. So the
breakpoint has to go at the JAL instruction instead, or 0x40071b.
To make a general case out of it we must never consider any jump or
branch instruction to be a part of a function's prologue. In the
presence of a jump or branch at the beginning of a function the furthest
instruction examined for the purpose of constructing frame information
can be one in the delay slot of that jump or branch if present, and
otherwise -- that is when the jump or branch is compact and has no delay
slot -- the instruction immediately preceding the jump or branch.
This change implements that approach across prologue scanners for the
three instruction ISAs. In implementing it I have factored out code
from the existing `*_instruction_has_delay_slot' handlers to be shared
and a side effect for the microMIPS implementation is it now always
fetches the second 16-bit halfword of 32-bit instructions even if it
eventually is not going to be needed. I think it's an acceptable
tradeoff for the purpose of code sharing.
To make things more consistent I also carried logic from
`micromips_scan_prologue' over to the other two scanners to accept (and
ignore) a single non-prologue non-control transfer instruction reordered
by the compiler into the prologue. While doing this I simplified the
exit path from the scan loop such that `end_prologue_addr' is set only
once. This made some concerns expressed in comments no longer
applicable, although even before they were not valid.
I have not fixed the logic around `load_immediate_bytes' in
`mips32_scan_prologue' though, it remains broken, although I took care
not to break it more. An approach similar to one taken for handling
larger stack adjustments in `micromips_scan_prologue' will have to be
eventually implemented here.
For regression testing I used my usual choice of the mips-linux-gnu
target and the following multilibs:
-EB
-EB -msoft-float
-EB -mips16
-EB -mips16 -msoft-float
-EB -mmicromips
-EB -mmicromips -msoft-float
-EB -mabi=n32
-EB -mabi=n32 -msoft-float
-EB -mabi=64
-EB -mabi=64 -msoft-float
and the -EL variants of same.
That removed gdb.dwarf2/dw2-skip-prologue.exp failures across MIPS16
multilibs, the test log now shows:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x40071b
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x0040071b in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
Breakpoint 2, func (param=0) at main.c:5
5 This program is free software; you can redistribute it and/or modify
(gdb) PASS: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- so things look like intended.
That also did regress, again across MIPS16 multilibs, another test case,
gdb.base/step-symless.exp:
(gdb) file .../gdb.d/gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x4006d3
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x004006d3 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
warning: GDB can't find the start of the function at 0x4006b9.
GDB is unable to find the start of the function at 0x4006b9
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006b9 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0x004006b9 in ?? ()
(gdb) FAIL: gdb.base/step-symless.exp: step
-- but that is actually a good sign. Here `main', again, has no debug
information and code involved looks like:
004006a0 <symful>:
4006a0: 6491 save 8,s1
4006a2: 673d move s1,sp
4006a4: b204 lw v0,4006b4 <symful+0x14>
4006a6: 9a40 lw v0,0(v0)
4006a8: 4261 addiu v1,v0,1
4006aa: b203 lw v0,4006b4 <symful+0x14>
4006ac: da60 sw v1,0(v0)
4006ae: 65b9 move sp,s1
4006b0: 6411 restore 8,s1
4006b2: e8a0 jrc ra
4006b4: 0041 addiu s0,sp,260
4006b6: 0860 la s0,400834 <__libc_start_main@mips16plt+0x54>
4006b8: 6491 save 8,s1
4006ba: 673d move s1,sp
4006bc: b204 lw v0,4006cc <symful+0x2c>
4006be: 9a40 lw v0,0(v0)
4006c0: 4261 addiu v1,v0,1
4006c2: b203 lw v0,4006cc <symful+0x2c>
4006c4: da60 sw v1,0(v0)
4006c6: 65b9 move sp,s1
4006c8: 6411 restore 8,s1
4006ca: e8a0 jrc ra
4006cc: 0041 addiu s0,sp,260
4006ce: 0860 la s0,40084c <__libc_start_main@mips16plt+0x6c>
004006d0 <main>:
4006d0: 64d4 save 32,ra,s1
4006d2: 1a00 01ae jal 4006b8 <symful+0x18>
4006d6: 0104 addiu s1,sp,16
4006d8: 1a00 01a8 jal 4006a0 <symful>
4006dc: 6500 nop
4006de: 6740 move v0,zero
4006e0: 65b9 move sp,s1
4006e2: 6452 restore 16,ra,s1
4006e4: e8a0 jrc ra
4006e6: 6500 nop
4006e8: 6500 nop
4006ea: 6500 nop
4006ec: 6500 nop
4006ee: 6500 nop
-- and the original log:
(gdb) file .../gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
Breakpoint 1 at 0x4006d9
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint 1 address previously adjusted from 0x004006dd to
0x004006d9.
Breakpoint 1, 0x004006d9 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
Breakpoint 2, 0x004006a5 in symful ()
(gdb) PASS: gdb.base/step-symless.exp: step
So the breakpoint at `main' was actually set at an instruction after the
call to `symful+0x18' aka `symless' and the test only passed because
single-stepping through `symless' wasn't actually done at all. With
this change in place this test fails for MIPS16 multilibs consistently
with all the other multilibs where it already failed in this manner
previously.
* mips-tdep.c (mips16_instruction_is_compact_branch): New
function.
(micromips_instruction_is_compact_branch): Likewise.
(mips16_scan_prologue): Terminate scanning upon seeing a branch
or a compact jump, reaching a jump delay slot, or seeing a
second non-prologue instruction.
(micromips_scan_prologue): Also terminate scanning upon seeing a
compact branch or jump, or reaching a branch or jump delay slot.
(mips32_scan_prologue): Terminate scanning upon reaching a branch
or jump delay slot, or seeing a second non-prologue instruction.
(mips32_instruction_has_delay_slot): Retain instruction
examination code only, update arguments accordingly and move
instruction fetch pieces to...
(mips32_insn_at_pc_has_delay_slot): ... this new function.
(micromips_instruction_has_delay_slot): Likewise and to...
(micromips_insn_at_pc_has_delay_slot): ... this new function.
(mips16_instruction_has_delay_slot): Likewise and to...
(mips16_insn_at_pc_has_delay_slot): ... this new function.
(mips_single_step_through_delay): Update accordingly.
(mips_adjust_breakpoint_address): Likewise.
This change addresses `micromips_instruction_has_delay_slot' and
`mips16_instruction_has_delay_slot' that both incorrectly interpret
their MUSTBE32 argument. Their callers assume that when the flag is
clear these functions will return 1 when any non-compact jump or branch
instruction is present at ADDR, while in fact they will only return 1
for 16-bit such instructions only. This change makes the implementation
match the expectations.
* mips-tdep.c (micromips_instruction_has_delay_slot): When
!mustbe32 also return 1 for 32-bit instructions.
(mips16_instruction_has_delay_slot): Likewise. Add an
explanatory comment.
In installing minimal symbols for ELF shared library trampolines
we "forget" to make individual symbols special where required. This
leads to problems on the MIPS target using microMIPS SVR4 lazy stubs.
Lacking the special annotation these stubs are treated as standard
MIPS code and this makes GDB insert the wrong software breakpoint
instruction, breaking e.g. single-stepping through these stubs. This
is not a very frequent scenario as microMIPS SVR4 lazy stubs are
typically only used in shared libraries with the main executable
using PLT, handled elsewhere. Still it triggers e.g. when a software
watchpoint has been installed. The symptom is SIGILL or the program
going astray, depending on the endianness. Disassembly of these stubs
is also wrong.
* elfread.c (elf_symtab_read): Also mark solib trampoline minimal
symbols special.
This change:
commit b775012e84
Author: Luis Machado <luisgpm@br.ibm.com>
Date: Fri Feb 24 15:10:59 2012 +0000
2012-02-24 Luis Machado <lgustavo@codesourcery.com>
* remote.c (remote_supports_cond_breakpoints): New forward
declaration.
[...]
changed the way breakpoints are inserted and removed such that
`insert_bp_location' can now be called with the breakpoint being handled
already in place, while previously the call was only ever made for
breakpoints that have not been put in place. This in turn caused an
issue for software breakpoints and targets for which a breakpoint's
`placed_address' may not be the same as the original requested address.
The issue is `insert_bp_location' overwrites the previously adjusted
value in `placed_address' with the original address, that is only
replaced back with the correct adjusted address later on when
`gdbarch_breakpoint_from_pc' is called. Meanwhile there's a window
where the value in `placed_address' does not correspond to data stored
in `shadow_contents', leading to incorrect instruction bytes being
supplied when `one_breakpoint_xfer_memory' is called to supply the
instruction overlaid by the breakpoint.
And this is exactly what happens on the MIPS target with software
breakpoints placed in microMIPS code. In this case not only
`placed_address' is not the original address because of the ISA bit, but
`mips_breakpoint_from_pc' has to read the original instruction to
determine which one of the two software breakpoint instruction encodings
to choose as well. The 16-bit encoding is used to replace 16-bit
instructions and similarly the 32-bit one is used with 32-bit
instructions, to satisfy branch delay slot size requirements.
The mismatch between `placed_address' and the address data in
`shadow_contents' has been obtained from leads to the wrong encoding
being used in some cases, which in the case of a 32-bit software
breakpoint instruction replacing a 16-bit instruction causes corruption
to the adjacent following instruction and leads the debug session astray
if execution reaches there e.g. with a jump.
To address this problem I made the change below, that adds a
`reqstd_address' field to `struct bp_target_info' and leaves
`placed_address' unchanged once it has been set. This ensures data in
`shadow_contents' is always consistent with `placed_address'.
This approach also has this good side effect that all the places that
examine the breakpoint's address see a consistent value, either
`reqstd_address' or `placed_address', as required. Currently some
places see either the original or the adjusted address in
`placed_address', depending on whether they have been called before
`gdbarch_remote_breakpoint_from_pc' or afterwards. This is in
particular true for subsequent calls to
`gdbarch_remote_breakpoint_from_pc' itself, e.g. from
`one_breakpoint_xfer_memory'. This is also important for places like
`find_single_step_breakpoint' where a breakpoint's address is compared
to the raw value of $pc.
* breakpoint.h (bp_target_info): Add `reqstd_address' member,
update comments.
* breakpoint.c (one_breakpoint_xfer_memory): Use `reqstd_address'
for the breakpoint's address. Don't preinitialize `placed_size'.
(insert_bp_location): Set `reqstd_address' rather than
`placed_address'.
(bp_target_info_copy_insertion_state): Also copy `placed_address'.
(bkpt_insert_location): Use `reqstd_address' for the breakpoint's
address.
(bkpt_remove_location): Likewise.
(deprecated_insert_raw_breakpoint): Likewise.
(deprecated_remove_raw_breakpoint): Likewise.
(find_single_step_breakpoint): Likewise.
* mem-break.c (default_memory_insert_breakpoint): Use
`reqstd_address' for the breakpoint's address. Don't set
`placed_address' or `placed_size' if breakpoint contents couldn't
have been determined.
* remote.c (remote_insert_breakpoint): Use `reqstd_address' for
the breakpoint's address.
(remote_insert_hw_breakpoint): Likewise. Don't set
`placed_address' or `placed_size' if breakpoint couldn't have been
set.
* aarch64-linux-nat.c (aarch64_linux_insert_hw_breakpoint): Use
`reqstd_address' for the breakpoint's address.
* arm-linux-nat.c (arm_linux_hw_breakpoint_initialize): Likewise.
* ia64-tdep.c (ia64_memory_insert_breakpoint): Likewise.
* m32r-tdep.c (m32r_memory_insert_breakpoint): Likewise.
* microblaze-linux-tdep.c
(microblaze_linux_memory_remove_breakpoint): Likewise.
* monitor.c (monitor_insert_breakpoint): Likewise.
* nto-procfs.c (procfs_insert_breakpoint): Likewise.
(procfs_insert_hw_breakpoint): Likewise.
* ppc-linux-nat.c (ppc_linux_insert_hw_breakpoint): Likewise.
* ppc-linux-tdep.c (ppc_linux_memory_remove_breakpoint): Likewise.
* remote-m32r-sdi.c (m32r_insert_breakpoint): Likewise.
* remote-mips.c (mips_insert_breakpoint): Likewise.
* x86-nat.c (x86_insert_hw_breakpoint): Likewise.
