... 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.
On MIPS64 little endian, attempting an assignment to a bit field
that lives in a register yields the wrong result. It just corrupts
the data in the register depending on the specific position of the
bit field inside the structure.
FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k
=== gdb Summary ===
Now, GDB knows how to do bit field assignment properly, but MIPS is
one of those architectures that uses a hook for the register-to-value
conversion. Although we can properly tell when the type being passed
is a structure or union, we cannot tell when it is a bit field,
because the bit field data lives in a value structure. Such data
only lives in a "type" structure when the parent structure is being
referenced, thus you can collect them from the flds_bnds members.
A bit field type structure looks pretty much the same as any other
primitive type like int or char, so we can't distinguish them.
Forcing more fields into the type structure wouldn't help much,
because the type structs are shared.
2014-10-03 Luis Machado <lgustavo@codesourcery.com>
* valops.c (value_assign): Check for bit field assignments
before calling architecture-specific register value
conversion functions.
Trying to debug gdb with itself,
I stumbled on the following complaints
Unknown symbol type 0x2e
or
Unknown symbol type 0x4e
It appears that those corrspond to N_BNSYM and N_ENSYM,
which are MacOS extensions of stabs debugging format.
But these extensions have been used inside gcc probalby
for a while already, see:
https://gcc.gnu.org/ml/gcc/2004-08/msg00157.html
As the only purpose of these entries is to allow for removal
of stabs information if the function is removed,
it can be safely ignored by GDB.
This patch simply adds those two entry types to the list
of ignored entry type in read_dbx_symtab function.
Is this OK?
Pierre Muller
2014-10-03 Pierre Muller <muller@sourceware.org>
* dbxread.c (read_dbx_symtab): Also ignore N_BNSYM/N_ENSYM.
In git b57bacec, I said:
> With that in place, the need to delay "Program received signal FOO"
> was actually caught by the manythreads.exp test. Without that bit, I
> was getting:
>
> [Thread 0x7ffff7f13700 (LWP 4499) exited]
> [New Thread 0x7ffff7f0b700 (LWP 4500)]
> ^C
> Program received signal SIGINT, Interrupt.
> [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
> [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
> __GI___nptl_death_event () at events.c:31
> 31 {
> (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
>
> That is, I was now getting "New Thread" lines after the "Program
> received signal" line, and the test doesn't expect them. As the
> number of new threads discovered before and after the "Program
> received signal" output is unbounded, it's much nicer to defer
> "Program received signal" until after synching the thread list, thus
> close to the "switching to thread" output and "current frame/source"
> info:
>
> [Thread 0x7ffff7863700 (LWP 7647) exited]
> ^C[New Thread 0x7ffff786b700 (LWP 7648)]
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
> __GI___nptl_create_event () at events.c:25
> 25 {
> (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
This commit factors out the two places in the test that are effected
by this, and adds there a destilled version of the comment above.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
(top level) <stop threads 1, stop threads 2>: Use it.
Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.
This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.
The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.
For example, in a program like this:
int
main (void)
{
pthread_t child_thread;
pthread_create (&child_thread, NULL, child_function, NULL);
return 0; <<<< set breakpoint here
}
If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread. So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.
The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem. That test sets a breakpoint while
the main thread is stopped, but other threads are running. Because
other threads are running, the breakpoint is supposed to be inserted
immediately. But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target. And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem... This commit adjust the test to exercise the case of not
issuing "info threads". The test then fails without the GDB fix.
In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed. For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.
The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped. We can't know
that until we fully sync the thread list. Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.
Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:
Native GNU/Linux debugging adds new threads to the thread list as
the program creates them "The [New Thread foo] messages". Remote
debugging can't do that, and it's arguable whether we shouldn't even
stop native debugging from doing that, as it hinders inferior
performance. However, a related issue is that with remote targets
(and gdbserver), even after the program stops, the user still needs
to do "info threads" to pull an updated thread list. This, should
most likely be addressed, so that GDB pulls the list itself, perhaps
just before presenting a stop to the user.
With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test. Without that bit, I
was getting:
[Thread 0x7ffff7f13700 (LWP 4499) exited]
[New Thread 0x7ffff7f0b700 (LWP 4500)]
^C
Program received signal SIGINT, Interrupt.
[New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
[Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
__GI___nptl_death_event () at events.c:31
31 {
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them. As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:
[Thread 0x7ffff7863700 (LWP 7647) exited]
^C[New Thread 0x7ffff786b700 (LWP 7648)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
__GI___nptl_create_event () at events.c:25
25 {
(gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoints_should_be_inserted_now): Use
threads_are_executing.
* breakpoint.h (breakpoints_should_be_inserted_now): Add
describing comment.
* gdbthread.h (threads_are_executing): Declare.
(handle_signal_stop) <random signals>: Don't print about the
signal here if stopping.
(end_stepping_range): Don't notify observers here.
(normal_stop): Update the thread list. If stopped by a random
signal or a stepping range ended, notify observers.
* thread.c (threads_executing): New global.
(init_thread_list): Clear 'threads_executing'.
(set_executing): Set or clear 'threads_executing'.
(threads_are_executing): New function.
(update_threads_executing): New function.
(update_thread_list): Use it.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument. Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.
Following an exec with "breakpoint always-inserted on" tries to insert
breakpoints in the new image at the addresses the symbols had in the
old image.
With "always-inserted off", we see:
gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
GNU gdb (GDB) 7.8.50.20140924-cvs
...
(gdb) b main
Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
^^^^^^^^
(gdb) c
The program is not being run.
(gdb) r
Starting program: testsuite/gdb.multi/multi-arch-exec
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello
Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
40 bar();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40
^^^^^^^^^^
breakpoint already hit 2 times
(gdb)
Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
gdb.multi/hello.
With "always-inserted on", we get:
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
infrun: target_wait (-1, status) =
infrun: 9444 [process 9444],
infrun: status->kind = execd
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXECD
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400664
(gdb)
That is, GDB is trying to insert a breakpoint at 0x400664, after the
exec, and then that address happens to not be mapped at all in the new
image.
The problem is that update_breakpoints_after_exec is creating
breakpoints, which ends up in update_global_location_list immediately
inserting breakpoints if "breakpoints always-inserted" is "on".
update_breakpoints_after_exec is called very early when we see an exec
event. At that point, we haven't loaded the symbols of the new
post-exec image yet, and thus haven't reset breakpoint's addresses to
whatever they may be in the new image. All we should be doing in
update_breakpoints_after_exec is deleting breakpoints that no longer
make sense after an exec. So the fix removes those breakpoint
creations.
The question is then, if not here, where are those breakpoints
re-created? Turns out we don't need to do anything else, because at
the end of follow_exec, we call breakpoint_re_set, whose tail is also
creating exactly the same breakpoints update_breakpoints_after_exec is
currently creating:
breakpoint_re_set (void)
{
...
create_overlay_event_breakpoint ();
create_longjmp_master_breakpoint ();
create_std_terminate_master_breakpoint ();
create_exception_master_breakpoint ();
}
A new test is added to exercise this.
Tested on x86_64 Fedora 20.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* breakpoint.c (update_breakpoints_after_exec): Don't create
overlay, longjmp, std terminate nor exception breakpoints here.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.
A patch I wrote made GDB pull the thread list sooner when debugging
with target remote, and I noticed an intended consequence. GDB
started bouncing around the currently selected remote/general thread
more frequently. E.g.:
Sending packet: $qTMinFTPILen#3b...Packet received: 5
+Sending packet: $Hgp726d.726d#53...Packet received: OK
Sending packet: $m400680,40#2f...Packet received: 85c0741455bff00d60004889e5ffd05de97bffffff0f1f00e973ffffff0f1f00554889e5c745fc00000000c745fc01000000e900000000c745fc02000000b800
+Sending packet: $Hgp726d.7278#28...Packet received: OK
Sending packet: $m4006b2,1#28...Packet received: e9
Fast tracepoint 2 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
This ended up breaking "tstart" when one has fast tracepoints set,
because gdbserver isn't expecting an Hg packet in response to
qRelocInsn:
(gdb) ftrace *set_point
Fast tracepoint 3 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
(gdb) PASS: gdb.trace/range-stepping.exp: ftrace: ftrace *set_point
tstart
gdbserver: Malformed response to qRelocInsn, ignoring: Hgp2783.2783
Target does not support this command.
(gdb) FAIL: gdb.trace/range-stepping.exp: ftrace: tstart
remote_trace_start should probably start by making sure the remote
current thread matches inferior_ptid (calling set_general_thread), but
still, reducing unnecessary bouncing is a good idea. It happens
because the memory/symbol/breakpoint routines use
switch_to_program_space_and_thread to do something in the right
context and then revert back to the previously current thread.
The fix is to simply make any_thread_of_process,
find_inferior_for_program_space, etc. give preference to the current
thread/inferior it if matches.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdbthread.h (any_thread_of_process, any_live_thread_of_process):
Adjust comments.
* inferior.c (find_inferior_for_program_space): Give preference to
the current inferior.
* inferior.h (find_inferior_for_program_space): Update comment.
* progspace.c (switch_to_program_space_and_thread): Prefer the
current inferior if it's bound to the program space requested. If
the inferior found doesn't have a PID yet, don't bother looking up
a thread.
* progspace.h (switch_to_program_space_and_thread): Adjust
comment.
* thread.c (any_thread_of_process, any_live_thread_of_process):
Give preference to the current thread.
Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:
(top-gdb) mem 0x443000 0x450000 ro
(top-gdb) set mem inaccessible-by-default off
(top-gdb) disassemble
Dump of assembler code for function main:
0x0000000000443956 <+34>: movq $0x0,0x10(%rax)
=> 0x000000000044395e <+42>: movq $0x0,0x18(%rax)
0x0000000000443966 <+50>: mov -0x24(%rbp),%eax
0x0000000000443969 <+53>: mov %eax,-0x20(%rbp)
End of assembler dump.
(top-gdb) b *0x0000000000443969
Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
(top-gdb) c
Continuing.
warning: cannot set software breakpoint at readonly address 0x443969
Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
29 args.argc = argc;
(top-gdb)
We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.
This is a regression; GDB used to fail inserting the breakpoint. More
below.
I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only. I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.
Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective. E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).
If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.
But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.
At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too. With
GDB 6.8 we had:
warning: cannot set software breakpoint at readonly address 0000000000443943
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x443943: Input/output error.
So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.
But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c. If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target. So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.
With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints. We need them today as software single-step breakpoints
bypass insert_bp_location. But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this. Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.
gdb/testsuite/
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
Don't reset the exit code at inferior exit and print it in
-list-thread-groups.
gdb/ChangeLog:
* NEWS: Announce new exit-code field in -list-thread-groups
output.
* inferior.c (exit_inferior_1): Don't clear exit code.
(inferior_appeared): Clear exit code.
* mi/mi-main.c (print_one_inferior): Add printing of the exit
code.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Miscellaneous gdb/mi Commands): Document new
exit-code field in -list-thread-groups output.
This makes it easier to rebuild all GDB's generated target description
C files.
It also clarifies the comments a bit. One might think we need a GDB
configured for the particular arquitecture (--target=foo). But a
build that includes support for the target description is sufficient.
(GDB rejects target descriptions that explicitly specify the
architecture, with an <architecture> element, if the architecture is
unknown.)
Tested that "make clean-cfiles" deletes all .c files under
src/gdb/features/, and that "make cfiles" generates them all without
error, and that diffing the newly generated C files against master
comes out an empty diff.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile: Update comments.
(XMLTOC): List all xml files we build C files from.
(clean-cfiles): New rule.
I regenerated all the .c files under src/gdb/features/ and this is
what I got.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/amd64-avx512-linux.c: Regenerate.
* features/i386/amd64-avx512.c: Regenerate.
* features/i386/x32-avx512-linux.c: Regenerate.
* features/i386/x32-avx512.c: Regenerate.
The only reason .dat files exist is for GBBserver to use them in its
build system.
A few .dat files are listed as targets for generation that shouldn't.
The target descriptions these files are built from aren't used by
GDBserver. They're fallback descriptions GDB itself has baked in.
Remove them from the list of .dat files to be generated, otherwise a
plain "make" under src/gdb/features/ generates new .dat files that
aren't even in the tree today.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (WHICH): Remove arm-with-m,
arm-with-m-fpa-layout and arm-with-m-vfp-d16.
So that we can do "make clean all" to regenerate all the renerated
.dat files.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (clean): New rule.
This file's format is invalid, as it's missing some end quotes.
I noticed this because I tried to regenerate all the .dat files in
gdb/regformats/. I got:
sh ../../move-if-change ../regformats/i386/x32-avx.tmp ../regformats/i386/x32-avx.dat
echo "# DO NOT EDIT: generated from i386/x32-avx512.xml" > ../regformats/i386/x32-avx512.tmp
echo "name:`echo x32-avx512 | sed 's/-/_/g'`" >> ../regformats/i386/x32-avx512.tmp
echo "xmltarget:x32-avx512.xml" >> ../regformats/i386/x32-avx512.tmp
echo "expedite:rbp,rsp,rip" \
>> ../regformats/i386/x32-avx512.tmp
xsltproc --path "/home/pedro/gdb/mygit/src/gdb/features" --xinclude number-regs.xsl i386/x32-avx512.xml | \
xsltproc sort-regs.xsl - | \
xsltproc gdbserver-regs.xsl - >> ../regformats/i386/x32-avx512.tmp
i386/64bit-avx512.xml:81: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : attributes construct error
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : Couldn't find end of Start Tag reg line 80
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : attributes construct error
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
...
i386/x32-avx512.xml:17: element include: XInclude error : could not load i386/64bit-avx512.xml, and no fallback was found
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
make: *** [../regformats/i386/x32-avx512.dat] Error 6
Interestingly, gdb/expat manages to grok the broken file.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/64bit-avx512.xml (zmm10h, zmm11h, zmm12h, zmm13h)
(zmm14h): Add missing end quotes.
This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
64bit.'.
Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
implementation is a bad idea.
In addition, while that commit intended to fix big endian Aarch64, it
ended up breaking floating point debugging against GDBserver, for both
big and little endian, because it changed the CPSR to be 64-bit in the
features/aarch64-core.xml file, but missed regenerating the
regformats/aarch64.dat file. If we generate it now, we see this:
diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
index afe1028..0d32183 100644
--- c/gdb/regformats/aarch64.dat
+++ w/gdb/regformats/aarch64.dat
@@ -35,7 +35,7 @@ expedite:x29,sp,pc
64:x30
64:sp
64:pc
-32:cpsr
+64:cpsr
128:v0
128:v1
128:v2
IOW, that commit left regformats/aarch64.dat still considering CPSR as
32-bits. regformats/aarch64.dat is used by GDBserver for its internal
regcache layout, and for the g/G packet register block. See the
generated aarch64.c file in GDBserver's build dir.
So the target description xml file that GDBserver reports to GDB is
now claiming that CPSR is 64-bit, but what GDBserver actually puts in
the g/G register packets is 32-bits. Because GDB thinks CPSR is
64-bit (because that's what the XML description says), GDB will be
reading the remaining 32-bit bits of CPSR out of v0 (the register
immediately afterwards), and then all the registers that follow CPSR
in the register packet end up wrong in GDB, because they're being read
from the wrong offsets...
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/aarch64-core.xml (cpsr): Change back to 32-bit.
* features/aarch64.c: Regenerate.
This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target. The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code. The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.
The changes are fairly mechanical. A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list. The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place. Although the order of some operations was changed, the
resulting functionality was not.
Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior. Some other adjustments were necessary
in inf-ttrace.c. The changes to inf-ttrace.c and inf-ptrace.c were not
tested.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
code so as to work with follow_fork_inferior.
* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
(inf_ttrace_create_inferior): Remove reference to
inf_ttrace_vfork_ppid.
(inf_ttrace_attach): Ditto.
(inf_ttrace_detach): Ditto.
(inf_ttrace_kill): Use current_inferior instead of
inf_ttrace_vfork_ppid.
(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
inferior away from the parent.
* infrun.c (follow_fork): Call follow_fork_inferior instead of
target_follow_fork.
(follow_fork_inferior): New function.
(follow_inferior_reset_breakpoints): Make function static.
* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
* linux-nat.c (linux_child_follow_fork): Move target-independent
code to infrun.c:follow_fork_inferior.
Now that all instances of the regset_from_core_section gdbarch method
have been replaced by the new iterator method, delete the obsolete
method from the gdbarch interface. Adjust all invocations and
references to it.
gdb/ChangeLog:
* gdbarch.sh (regset_from_core_section): Remove gdbarch method.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* corelow.c (sniff_core_bfd): Drop presence check for deleted
gdbarch method 'regset_from_core_section'.
(get_core_register_section): Remove handling for the case that
regset == NULL and regset_from_core_section is defined.
(get_core_registers): Drop check for deleted method.
* procfs.c (procfs_do_thread_registers): Adjust comment.
Now that all Linux targets use the regset iterator, the fall back to
the deprecated target method is dropped.
gdb/ChangeLog:
* linux-nat.c (linux_nat_collect_thread_registers): Remove.
(linux_nat_make_corefile_notes): Remove.
(linux_target_install_ops): Do not set target method
'make_corefile_notes'.
* linux-tdep.c (struct linux_corefile_thread_data)<collect>:
Remove field.
(linux_corefile_thread_callback): Instead of args->collect, call
linux_collect_thread_registers.
(linux_make_corefile_notes): Remove 'collect' parameter. Return
NULL unless there is a regset iterator.
(linux_make_corefile_notes_1): Remove.
(linux_init_abi): Replace reference to linux_make_corefile_notes_1
by linux_make_corefile_notes.
* linux-tdep.h (linux_make_corefile_notes): Remove prototype.
Now that all users of the target method 'fbsd_make_corefile_notes'
have been converted to the version in fbsd-tdep.c, the old method is
removed.
gdb/ChangeLog:
* fbsd-nat.c (find_signalled_thread, find_stop_signal)
(fbsd_collect_regset_section_cb, fbsd_make_corefile_notes):
Remove.
* fbsd-nat.h (fbsd_make_corefile_notes): Remove prototype.
For TILE-Gx GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* tilegx-linux-tdep.c (TILEGX_LINUX_SIZEOF_GREGSET): New macro.
(tilegx_regset_from_core_section): Remove.
(tilegx_iterate_over_regset_sections): New.
(tilegx_linux_init_abi): Adjust gdbarch initialization.
For Super-H targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* sh-linux-tdep.c (sh_linux_init_abi): Set tdep fields
'sizeof_gregset' and 'sizeof_fpregset'.
* sh-tdep.c (sh_regset_from_core_section): Remove.
(sh_iterate_over_regset_sections): New.
(sh_gdbarch_init): Adjust gdbarch initialization.
* sh-tdep.h (struct gdbarch_tdep): New fields sizeof_gregset and
sizeof_fpregset.
* shnbsd-tdep.c (shnbsd_init_abi): Set tdep field
'sizeof_gregset'.
For Nios II GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* nios2-linux-tdep.c (NIOS2_GREGS_SIZE): New macro.
(nios2_regset_from_core_section): Remove.
(nios2_iterate_over_regset_sections): New.
(nios2_linux_init_abi): Adjust gdbarch initialization.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. Do this for GNU/Linux- as well as
Net/OpenBSD-targets. In the case of GNU/Linux this should enable
non-native use of the 'generate-core-file' command.
gdb/ChangeLog:
* alpha-linux-tdep.c (alpha_linux_regset_from_core_section): Remove.
(alpha_linux_iterate_over_regset_sections): New.
(alpha_linux_init_abi): Adjust gdbarch initialization.
* alphabsd-tdep.h (alphanbsd_regset_from_core_section): Remove
prototype.
(alphanbsd_iterate_over_regset_sections): New prototype.
* alphafbsd-tdep.c (alphafbsd_init_abi): Add comment for missing
fbsd_init_abi invocation.
* alphanbsd-tdep.c (alphanbsd_supply_gregset): Move below
alphanbsd_aout_supply_gregset. Invoke the latter for the
appropriate size.
(alphanbsd_aout_gregset): Remove.
(alphanbsd_regset_from_core_section): Remove.
(alphanbsd_iterate_over_regset_sections): New.
(alphanbsd_init_abi): Adjust gdbarch initialization.
* alphaobsd-tdep.c (alphaobsd_init_abi): Likewise.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. This slightly reduces the code and enables non-native
use of the 'generate-core-file' command.
Also, when all instances of 'regset_from_core_section' are replaced,
it can be dropped from the gdbarch interface.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_regset_from_core_section):
Remove.
(aarch64_linux_iterate_over_regset_sections): New.
(aarch64_linux_init_abi): Adjust gdbarch initialization.
This creates a new version of the FreeBSD core file note generation
logic in the new target-dependent file "fbsd-tdep.c". The new version
is mostly copied from "fbsd-nat.c", but uses the iterator instead of
regset_from_core_section and defines fbsd_make_corefile_notes as a
gdbarch method instead of a target method.
Consecutive architecture-dependent changes exploit the new version,
migrating away from the target method. When all FreeBSD targets are
changed, the target method can go away.
gdb/ChangeLog:
* fbsd-tdep.c: New file.
* fbsd-tdep.h: New file.
* Makefile.in (ALL_TARGET_OBS): Add fbsd-tdep.o.
(HFILES_NO_SRCDIR): Add fbsd-tdep.h.
(ALLDEPFILES): Add fbsd-tdep.c.
This adds the 'regset' parameter to the iterator callback.
Consequently the 'regset_from_core_section' method is dropped for all
targets that provide the iterator method.
This change prepares for replacing regset_from_core_section
everywhere, thereby eliminating one gdbarch interface. Since the
iterator is usually no more complex than regset_from_core_section
alone, targets that previously didn't define core_regset_sections will
then gain multi-arch capable core file generation support without
increased complexity.
gdb/ChangeLog:
* gdbarch.sh (iterate_over_regset_sections_cb): Add regset
parameter.
* gdbarch.h: Regenerate.
* corelow.c (sniff_core_bfd): Don't sniff if gdbarch has a regset
iterator.
(get_core_register_section): Add parameter 'regset' and use it, if
set. Add parameter 'min_size' and verify the bfd section size
against it.
(get_core_registers_cb): Add parameter 'regset' and pass it to
get_core_register section. For the "standard" register sections
".reg" and ".reg2", set an appropriate default for human_name.
(get_core_registers): Don't abort when the gdbarch has an iterator
but no regset_from_core_section. Add NULL/0 for parameters
'regset'/'min_size' in calls to get_core_register_section.
* linux-tdep.c (linux_collect_regset_section_cb): Add parameter
'regset' and use it instead of calling the
regset_from_core_section gdbarch method.
* i386-tdep.h (struct gdbarch_tdep): Add field 'fpregset'.
* i386-tdep.c (i386_supply_xstateregset)
(i386_collect_xstateregset, i386_xstateregset): Moved to
i386-linux-tdep.c.
(i386_regset_from_core_section): Drop handling for .reg-xfp and
.reg-xstate.
(i386_gdbarch_init): Set tdep field 'fpregset'. Enable generic
core file support only if the regset iterator hasn't been set.
* i386-linux-tdep.c (i386_linux_supply_xstateregset)
(i386_linux_collect_xstateregset, i386_linux_xstateregset): New.
Moved from i386-tdep.c and renamed to *_linux*.
(i386_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation. Allow any .reg-xstate size when reading
from a core file.
* amd64-tdep.c (amd64_supply_xstateregset)
(amd64_collect_xstateregset, amd64_xstateregset): Moved to
amd64-linux-tdep.c.
(amd64_regset_from_core_section): Remove.
(amd64_init_abi): Set new tdep field 'fpregset'. No longer
install an amd64-specific regset_from_core_section gdbarch method.
* amd64-linux-tdep.c (amd64_linux_supply_xstateregset)
(amd64_linux_collect_xstateregset, amd64_linux_xstateregset): New.
Moved from amd64-tdep.c and renamed to *_linux*.
(amd64_linux_iterate_over_regset_sections): Add regset parameter
to each callback invocation. Allow any .reg-xstate size when
reading from a core file.
* arm-linux-tdep.c (arm_linux_regset_from_core_section): Remove.
(arm_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(arm_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* ppc-linux-tdep.c (ppc_linux_regset_from_core_section): Remove.
(ppc_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(ppc_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* s390-linux-tdep.c (struct gdbarch_tdep): Remove the fields
gregset, sizeof_gregset, fpregset, and sizeof_fpregset.
(s390_regset_from_core_section): Remove.
(s390_iterate_over_regset_sections): Add regset parameter to each
callback invocation.
(s390_gdbarch_init): No longer set the regset_from_core_section
gdbarch method. Drop initialization of deleted tdep fields.
The core_regset_sections list in gdbarch (needed for multi-arch
capable core file generation support) is replaced by an iterator
method. Overall, this reduces the code a bit, and it allows for more
flexibility.
gdb/ChangeLog:
* amd64-linux-tdep.c (amd64_linux_regset_sections): Remove.
(amd64_linux_iterate_over_regset_sections): New.
(amd64_linux_init_abi_common): Don't install the regset section
list, but the new iterator in gdbarch.
* arm-linux-tdep.c (arm_linux_fpa_regset_sections)
(arm_linux_vfp_regset_sections): Remove. Move combined logic...
(arm_linux_iterate_over_regset_sections): ...here. New function.
(arm_linux_init_abi): Set iterator instead of section list.
* corelow.c (get_core_registers_cb): New function, logic moved
from...
(get_core_registers): ...loop body here. Use new iterator method
instead of walking through the regset section list.
* gdbarch.sh: Remove 'core_regset_sections'. New method
'iterate_over_regset_sections'. New typedef
'iterate_over_regset_sections_cb'.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* i386-linux-tdep.c (i386_linux_regset_sections)
(i386_linux_sse_regset_sections, i386_linux_avx_regset_sections):
Remove.
(i386_linux_iterate_over_regset_sections): New.
(i386_linux_init_abi): Don't choose a regset section list, but
install new iterator in gdbarch.
* linux-tdep.c (struct linux_collect_regset_section_cb_data): New.
(linux_collect_regset_section_cb): New function, logic moved
from...
(linux_collect_thread_registers): ...loop body here. Use iterator
method instead of walking through list.
(linux_make_corefile_notes_1): Check for presence of iterator
method instead of regset section list.
* ppc-linux-tdep.c (ppc_linux_vsx_regset_sections)
(ppc_linux_vmx_regset_sections, ppc_linux_fp_regset_sections)
(ppc64_linux_vsx_regset_sections, ppc64_linux_vmx_regset_sections)
(ppc64_linux_fp_regset_sections): Remove. Move combined logic...
(ppc_linux_iterate_over_regset_sections): ...here. New function.
(ppc_linux_init_abi): Don't choose from above regset section
lists, but install new iterator in gdbarch.
* regset.h (struct core_regset_section): Remove.
* s390-linux-tdep.c (struct gdbarch_tdep): Add new fields
have_linux_v1, have_linux_v2, and have_tdb.
(s390_linux32_regset_sections, s390_linux32v1_regset_sections)
(s390_linux32v2_regset_sections, s390_linux64_regset_sections)
(s390_linux64v1_regset_sections, s390_linux64v2_regset_sections)
(s390x_linux64_regset_sections, s390x_linux64v1_regset_sections)
(s390x_linux64v2_regset_sections): Remove. Move combined logic...
(s390_iterate_over_regset_sections): ...here. New function. Use
new tdep fields.
(s390_gdbarch_init): Set new tdep fields. Don't choose from above
regset section lists, but install new iterator.
I see the following fails on arm-linux-gnueabi,
result of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is 1
output of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is not a dynamic executable
child process exited abnormally
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so output contains libs
the test script invokes ldd (on host) for the target libraries, which
is wrong. ldd can't be cross because it invokes dynamic linker with
LD_TRACE_LOADED_OBJECTS and gets the dependent libraries. My first
reaction to this problem is to execute ld.so on the target (like
remote_exec target). When I start to hack proc build_executable_own_libs,
I find it has assumptions here and there that the native testing is
performed. Then I check the callers of build_executable_own_libs,
and they are all skipped if isnative is false. It is reasonable to do
the same in dlopen-libpthread.exp too.
gdb/testsuite:
2014-09-30 Yao Qi <yao@codesourcery.com>
* gdb.threads/dlopen-libpthread.exp: Skip it if isnative is
false.
commit 2268b414f4
added file "features/library-list-svr4.dtd" but the added code uses
"library-list.dtd" instead.
Curiously after changing for a test s/name/nXme/ in the DTD making the
gdbserver output non-conforming there is no warning or regression seen (tested
gdb.base/shlib-call.exp, using_xfer is still 1). I did not check more why the
DTD conformance verification does not work.
gdb/ChangeLog
2014-09-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* solib-svr4.c (svr4_parse_libraries): Use "library-list-svr4.dtd".
Remove the pruning of program spaces in print_program_space to remove
unwanted side-effects. "info" commands and print routines should
generally not change the state of the debugger.
gdb/Changelog:
* progspace.c (print_program_space): Don't prune program spaces
before printing them.
What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.
/* Return a ptid representing the set of threads that we will proceed,
in the perspective of the user/frontend. */
extern ptid_t user_visible_resume_ptid (int step);
Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.
Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.
Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (user_visible_resume_ptid): Don't check
singlestep_breakpoints_inserted_p.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (stepping_past_instruction_at)
(clear_exit_convenience_vars): Point at infrun.h instead of
inferior.h.
(handle_signal_stop): Fix typo.
This patch fixes a typo in the bit mask I've made in my previous code
refactor. If PC is in the register list, the bit 8 is one, so bit
mask 0xff00 should be used. Current condition is a constant false.
gdb:
2014-09-24 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Fix typo in the
bitmask.
I see the following fail on arm-none-linux-gnueabi testing,
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
[Switching to Thread 1003]^M
handler (signo=10) at
/scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.threads/sigstep-threads.c:33^M
33 tgkill (getpid (), gettid (), SIGUSR1); /* step-2 */^M
(gdb) FAIL: gdb.threads/sigstep-threads.exp: continue
the cause is that GDBserver doesn't cancel the breakpoint if the stop
signal is SIGILL. The kernel used here is a little old, 2.6.x, and
doesn't translate SIGILL to SIGTRAP when program hits breakpoint
instruction (which is an illegal instruction actually). GDB and
GDBserver can translate SIGILL to SIGTRAP under certain circumstance,
so it is not a problem here. See gdbserver/linux-low.c:linux_wait_1
/* If this event was not handled before, and is not a SIGTRAP, we
report it. SIGILL and SIGSEGV are also treated as traps in case
a breakpoint is inserted at the current PC. If this target does
not support internal breakpoints at all, we also report the
SIGTRAP without further processing; it's of no concern to us. */
maybe_internal_trap
= (supports_breakpoints ()
&& (WSTOPSIG (w) == SIGTRAP
|| ((WSTOPSIG (w) == SIGILL
|| WSTOPSIG (w) == SIGSEGV)
&& (*the_low_target.breakpoint_at) (event_child->stop_pc))));
However, SIGILL and SIGSEGV is not considered when cancelling
breakpoint, which causes the fail above. That is, when GDB is doing
software single step on address ADDR, both thread A and thread B hits the
software single step breakpoint, and get SIGILL. GDB selects the event
from thread A, removes the software single step breakpoint, and resume
the program. The event (SIGILL) from thread B is reported to GDB, but
GDB doesn't regard this SIGILL as SIGTRAP, because the breakpoint on
address ADDR was removed, so GDB reports "Program received signal
SIGILL".
The patch is to allow calling cancel_breakpoint if the signal is
SIGILL and SIGSEGV. This patch fixes the fail above. Likewise, event
lwp selection should honour SIGILL and SIGSEGV too.
gdb/gdbserver:
2014-09-23 Yao Qi <yao@codesourcery.com>
* linux-low.c (lp_status_maybe_breakpoint): New function.
(linux_low_filter_event): Call lp_status_maybe_breakpoint.
(count_events_callback): Likewise.
(select_event_lwp_callback): Likewise.
(cancel_breakpoints_callback): Likewise.
This commit renames target_stop_ptid as target_stop_and_wait and
target_continue_ptid as target_continue_no_signal. Comments are
updated to more fully describe the functions' behaviour.
gdb/ChangeLog:
* target/target.h (target_stop_ptid): Renamed as...
(target_stop_and_wait): New function. Updated comment.
All uses updated.
(target_continue_ptid): Renamed as...
(target_continue_no_signal): New function. Updated comment.
All uses updated.
By default, GDB removes all breakpoints from the target when the
target stops and the prompt is given back to the user. This is useful
in case GDB crashes while the user is interacting, as otherwise,
there's a higher chance breakpoints would be left planted on the
target.
But, as long as any thread is running free, we need to make sure to
keep breakpoints inserted, lest a thread misses a breakpoint. With
that in mind, in preparation for non-stop mode, we added a "breakpoint
always-inserted on" mode. This traded off the extra crash protection
for never having threads miss breakpoints, and in addition is more
efficient if there's a ton of breakpoints to remove/insert at each
user command (e.g., at each "step").
When we added non-stop mode, and for a period, we required users to
manually set "always-inserted on" when they enabled non-stop mode, as
otherwise GDB removes all breakpoints from the target as soon as any
thread stops, which means the other threads still running will miss
breakpoints. The test added by this patch exercises this.
That soon revealed a nuisance, and so later we added an extra
"breakpoint always-inserted auto" mode, that made GDB behave like
"always-inserted on" when non-stop was enabled, and "always-inserted
off" when non-stop was disabled. "auto" was made the default at the
same time.
In hindsight, this "auto" setting was unnecessary, and not the ideal
solution. Non-stop mode does depends on breakpoints always-inserted
mode, but only as long as any thread is running. If no thread is
running, no breakpoint can be missed. The same is true for all-stop
too. E.g., if, in all-stop mode, and the user does:
(gdb) c&
(gdb) b foo
That breakpoint at "foo" should be inserted immediately, but it
currently isn't -- currently it'll end up inserted only if the target
happens to trip on some event, and is re-resumed, e.g., an internal
breakpoint triggers that doesn't cause a user-visible stop, and so we
end up in keep_going calling insert_breakpoints. The test added by
this patch also covers this.
IOW, no matter whether in non-stop or all-stop, if the target fully
stops, we can remove breakpoints. And no matter whether in all-stop
or non-stop, if any thread is running in the target, then we need
breakpoints to be immediately inserted. And then, if the target has
global breakpoints, we need to keep breakpoints even when the target
is stopped.
So with that in mind, and aiming at reducing all-stop vs non-stop
differences for all-stop-on-stop-of-non-stop, this patch fixes
"breakpoint always-inserted off" to not remove breakpoints from the
target until it fully stops, and then removes the "auto" setting as
unnecessary. I propose removing it straight away rather than keeping
it as an alias, unless someone complains they have scripts that need
it and that can't adjust.
Tested on x86_64 Fedora 20.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* NEWS: Mention merge of "breakpoint always-inserted" modes "off"
and "auto" merged.
* breakpoint.c (enum ugll_insert_mode): New enum.
(always_inserted_mode): Now a plain boolean.
(show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO.
(breakpoints_always_inserted_mode): Delete.
(breakpoints_should_be_inserted_now): New function.
(insert_breakpoints): Pass UGLL_INSERT to
update_global_location_list instead of calling
insert_breakpoint_locations manually.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode.
(_initialize_breakpoint): "breakpoint always-inserted" option is
now a boolean command. Update help text.
* breakpoint.h (breakpoints_always_inserted_mode): Delete declaration.
(breakpoints_should_be_inserted_now): New declaration.
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Remove breakpoints_always_inserted_mode check.
(normal_stop): Adjust to use breakpoints_should_be_inserted_now.
* remote.c (remote_start_remote): Likewise.
gdb/doc/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Set Breaks): Document that "set breakpoint
always-inserted off" is the default mode now. Delete
documentation of "set breakpoint always-inserted auto".
gdb/testsuite/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp: New file.
* gdb.threads/break-while-running.c: New file.
This adds a new mode for update_global_location_list, that allows
callers saying "please insert breakpoints, even if
breakpoints_always_inserted_mode() is false". This allows removing a
couple breakpoints_always_inserted_mode checks.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): Add UGLL_INSERT.
(insert_breakpoints): Don't call insert_breakpoint_locations here.
Instead, pass UGLL_INSERT to update_global_location_list.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Handle UGLL_INSERT.
Later we'll want a tristate, but for now, convert to an enum that maps 1-1
with the current boolean's true/false.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): New enum.
(update_global_location_list)
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode. All callers adjusted.
This commit implements functions for identifying and extracting extended
ptrace event information from a Linux wait status. These are just
convenience functions intended to hide the ">> 16" used to extract the
event from the wait status word, replacing the hard-coded shift with a more
descriptive function call. This is preparatory work for implementation of
follow-fork and detach-on-fork for extended-remote linux targets.
gdb/ChangeLog:
* linux-nat.c (linux_handle_extended_wait): Call
linux_ptrace_get_extended_event.
(wait_lwp): Call linux_is_extended_waitstatus.
(linux_nat_filter_event): Call linux_ptrace_get_extended_event
and linux_is_extended_waitstatus.
* nat/linux-ptrace.c (linux_test_for_tracefork): Call
linux_ptrace_get_extended_event.
(linux_ptrace_get_extended_event): New function.
(linux_is_extended_waitstatus): New function.
* nat/linux-ptrace.h (linux_ptrace_get_extended_event)
(linux_is_extended_waitstatus): New declarations.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Call
linux_ptrace_get_extended_event.
(get_stop_pc, get_detach_signal, linux_low_filter_event): Call
linux_is_extended_waitstatus.
---
This patch is to extend dw2-var-zero-add.exp to cover the case that
partial symtabl is not used while full symtab is used, in order to
cover the changes in patch 2/3. This patch restarts GDB with
--readnow and does the same test again.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test.
Invoke test. Restart GDB with --readnow and invoke test again.
I see the following fail on arm-none-eabi target,
(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24
Currently, we are using flag has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed, like this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
However, this is incorrect on some bare metal targets, as .text
section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero
is true. If a function is GC'ed by linker, the address is zero. GDB
thinks address zero is a function's address rather than this function
is GC'ed.
In this patch, we choose 'lowpc' got in read_file_scope to check
whether 'lowpc' is greater than zero. If it isn't, address zero really
means the function is GC'ed. In this patch, we pass 'lowpc' in
read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines,
and to dwarf_decode_lines_1 finally.
This patch fixes the fail above. This patch also covers the path that
partial symbol isn't used, which is tested by starting gdb with
--readnow option.
It is regression tested on x86-linux with
target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply?
gdb:
2014-09-19 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Add argument 'lowpc'. Update
comments. Callers update.
(dwarf_decode_lines): Likewise.
(dwarf_decode_lines_1): Add argument 'lowpc'. Update
comments. Skip the line table if 'lowpc' is greater than
'address'. Don't check
dwarf2_per_objfile->has_section_at_zero.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
If accessing memory via safe_read_memory_integer fails, that function
used to print an error message even though callers were perfectly able
to handle (and even expected!) failures.
This patch removes the confusing message by changing the routine to
directly use target_read_memory.
gdb/ChangeLog:
PR gdb/17384
* corefile.c (struct captured_read_memory_integer_arguments): Remove.
(do_captured_read_memory_integer): Remove.
(safe_read_memory_integer): Use target_read_memory directly instead
of catching errors in do_captured_read_memory_integer.
This is just a testcase addition that I am proposing for upstream GDB.
We have this in our internal tree, and the related RH bug is:
<https://bugzilla.redhat.com/show_bug.cgi?id=809179>
(You might not be able to see all the comments without privileges.)
This bug is about a global variable that got incorrectly displayed by
GDB. This bug has already been fixed a long time ago by Joel's
commit:
commit 19630284f5
Author: Joel Brobecker <brobecker@gnat.com>
Date: Tue Jun 5 13:50:50 2012 +0000
But I think a testcase for it wouldn't hurt.
So, consider the following scenario:
$ cat solib1.c
int test;
void c_main (void)
{
test = 42;
}
$ cat solib2.c
int test;
void b_main (void)
{
test = 42;
}
$ cat main.c
int main (int argc, char *argv[])
{
c_main ();
b_main ();
return 0;
}
$ gcc -g -fPIC -shared -o libSO1.so -c solib1.c
$ gcc -g -fPIC -shared -o libSO2.so -c solib2.c
$ gcc -g -o main -L$PWD -lSO1 -lSO2 main.c
$ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main
...
$1 = 0
This happened with GDB before Joel's commit above. Now, things work
and GDB is able to correctly display the nested global variable:
$ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main
...
$1 = 42
The testcase attached tests this behavior.
gdb/testsuite/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/global-var-nested-by-dso-solib1.c: New file.
* gdb.base/global-var-nested-by-dso-solib2.c: Likewise.
* gdb.base/global-var-nested-by-dso.c: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
In gdb/gdbserver/Makefile.in, IPAGENT_CFLAGS is defined using
an expression which references $(CPPFLAGS). But CPPFLAGS isn't
actually defined.
This patch first adds a CPPFLAGS definition, so as to inherit
the value passed at configure time (if any). And it then makes it
part of INTERNAL_CFLAGS_BASE, instead. There is no reason that
CPPFLAGS be useful for a certain class of source files, and not
the rest. This is also consistent with what's done in GDB.
gdb/gdbserver/ChangeLog:
* Makefile.in (CPPFLAGS): Define.
(INTERNAL_CFLAGS_BASE): Add ${CPPFLAGS}.
(IPAGENT_CFLAGS): Remove ${CPPFLAGS}.
Tested by rebuilding GDBserver with a dummy CPPFLAGS, and verifying
that the compilation command was altered as expected.
This obvious change removes dead code from objc-lang.c. I was
grepping for "fprintf (stderr..." and found this code between "#if
0".."#endif" blocks.
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* objc-lang.c (find_implementation_from_class): Remove dead code.
This is an obvious replacement of "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...", which is the standard to use in
these cases.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/7233
* linux-nat.c (linux_nat_wait_1): Replace "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...)".
Make test messages unique and a couple other tweaks.
gdb/testsuite/
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/watch-bitfields.exp: Pass string other than test file
name to prepare_for_testing.
(watch): New procedure.
(expect_watchpoint): Use with_test_prefix.
(top level): Factor out tests to ...
(test_watch_location, test_regular_watch): ... these new
procedures, and use with_test_prefix and gdb_continue_to_end.
PR 12526 reports that -location watchpoints against bitfield arguments
trigger false positives when bits around the bitfield, but not the
bitfield itself, are modified.
This happens because -location watchpoints naturally operate at the
byte level, not at the bit level. When the address of a bitfield
lvalue is taken, information about the bitfield (i.e. its offset and
size) is lost in the process.
This information must first be retained throughout the lifetime of the
-location watchpoint. This patch achieves this by adding two new
fields to the watchpoint struct: val_bitpos and val_bitsize. These
fields are set when a watchpoint is first defined in watch_command_1.
They are both equal to zero if the watchpoint is not a -location
watchpoint or if the argument is not a bitfield.
Then these bitfield parameters are used inside update_watchpoint and
watchpoint_check to extract the actual value of the bitfield from the
watchpoint address, with the help of a local helper function
extract_bitfield_from_watchpoint_value.
Finally when creating a HW breakpoint pointing to a bitfield, we
optimize the address and length of the breakpoint. By skipping over
the bytes that don't cover the bitfield, this step reduces the
frequency at which a read watchpoint for the bitfield is triggered.
It also reduces the number of times a false-positive call to
check_watchpoint is triggered for a write watchpoint.
gdb/
PR breakpoints/12526
* breakpoint.h (struct watchpoint): New fields val_bitpos and
val_bitsize.
* breakpoint.c (watch_command_1): Use these fields to retain
bitfield information.
(extract_bitfield_from_watchpoint_value): New function.
(watchpoint_check): Use it.
(update_watchpoint): Use it. Optimize the address and length of a
HW watchpoint pointing to a bitfield.
* value.h (unpack_value_bitfield): New prototype.
* value.c (unpack_value_bitfield): Make extern.
gdb/testsuite/
PR breakpoints/12526
* gdb.base/watch-bitfields.exp: New file.
* gdb.base/watch-bitfields.c: New file.
"target vxworks" and friends have been removed 10 years ago already:
commit e84ecc995d
Author: Andrew Cagney <cagney@redhat.com>
AuthorDate: Sat Nov 13 23:10:02 2004 +0000
2004-11-13 Andrew Cagney <cagney@gnu.org>
* configure.tgt: Delete i[34567]86-*-vxworks*, m68*-netx-*,
m68*-*-vxworks*, mips*-*-vxworks*, powerpc-*-vxworks*, and
sparc-*-vxworks*.
* NEWS: Mention that vxworks was deleted.
(...)
* remote-vxmips.c, remote-vx.c: Delete.
* remote-vx68.c: Delete.
(...)
This removes related leftover cruft from the manual.
gdb/doc/
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Starting) <run command>: Don't mention VxWorks.
(Embedded OS): Remove VxWorks menu entry.
(VxWorks): Remove node.
GDB has a function named "current_inferior" and gdbserver has a global
variable named "current_inferior", but the two are not equivalent;
indeed, gdbserver does not have any real equivalent of what GDB calls
an inferior. What gdbserver's "current_inferior" is actually pointing
to is a structure describing the current thread. This commit renames
current_inferior as current_thread in gdbserver to clarify this. It
also renames the function "set_desired_inferior" to "set_desired_thread"
and renames various local variables from foo_inferior to foo_thread.
gdb/gdbserver/ChangeLog:
* inferiors.h (current_inferior): Renamed as...
(current_thread): New variable. All uses updated.
* linux-low.c (get_pc): Renamed saved_inferior as saved_thread.
(maybe_move_out_of_jump_pad): Likewise.
(cancel_breakpoint): Likewise.
(linux_low_filter_event): Likewise.
(wait_for_sigstop): Likewise.
(linux_resume_one_lwp): Likewise.
(need_step_over_p): Likewise.
(start_step_over): Likewise.
(linux_stabilize_threads): Renamed save_inferior as saved_thread.
* linux-x86-low.c (x86_linux_update_xmltarget): Likewise.
* proc-service.c (ps_lgetregs): Renamed reg_inferior as reg_thread
and save_inferior as saved_thread.
* regcache.c (get_thread_regcache): Renamed saved_inferior as
saved_thread.
(regcache_invalidate_thread): Likewise.
* remote-utils.c (prepare_resume_reply): Likewise.
* thread-db.c (thread_db_get_tls_address): Likewise.
(disable_thread_event_reporting): Likewise.
(remove_thread_event_breakpoints): Likewise.
* tracepoint.c (gdb_agent_about_to_close): Renamed save_inferior
as saved_thread.
* target.h (set_desired_inferior): Renamed as...
(set_desired_thread): New declaration. All uses updated.
* server.c (myresume): Updated comment to reference thread instead
of inferior.
(handle_serial_event): Likewise.
(handle_target_event): Likewise.
Silly typo...
gdb/testsuite/
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.exp (test): Compare
software and hardware addresses, not software address against
itself.
This adds a test that makes sure GDB knows whether the target has
continuable, or non-continuable watchpoints.
That is, the test confirms that GDB presents a watchpoint value change
at the first instruction right after the instruction that changes
memory.
gdb/testsuite/ChangeLog:
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.c: New file.
* gdb.base/watchpoint-stops-at-right-insn.exp: New file.
In the recent review to my patch about copying files to remote host,
we find that we need a board file which is more closely mapped real
remote host testing to improve coverage. With the board file
local-remote-host-native.exp, DejaGNU copies files to
$build/gdb/testsuite/remote-host to emulate the effect of remote host.
Is it OK?
gdb/testsuite:
2014-09-16 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-native.exp: New file.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Added record handler for
vector data transfer instructions.
(arm_record_coproc_data_proc): Updated.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_coproc_data_proc): Add record handler stubs
for asimd, vfp and coprocessor insns.
(arm_record_asimd_vfp_coproc): Add record handler for asimd, vfp
and coprocessor insns.
(thumb2_record_coproc_insn): New function.
(thumb2_record_decode_insn_handler): Update coprocessor insns record
handlers.
(decode_insn): Install arm_record_asimd_vfp_coproc as handler for
opcode 110 insns.
The test does a backtrace to see which thread (#2 or #3) is assigned
to which SIGUSR (1 or 2). If the main thread gets to all_threads_running
before the sigusr threads get to their entry point, then the function
name isn't in the backtrace and the test fails.
Alas this version of the code is within epsilon of what I started with,
and then over-simplified things.
If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".
This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.
One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command. I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.
gdb/ChangeLog:
* NEWS: Mention new "queue-signal" command.
* infcmd.c (queue_signal_command): New function.
(_initialize_infcmd): Add new queue-signal command.
gdb/doc/ChangeLog:
* gdb.texinfo (Signaling): Document new queue-signal command.
gdb/testsuite/ChangeLog:
* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.
I had occasion to use with_gdb_prompt in a test for the patch for PR 17314
and was passing the plain text prompt as the value, "(top-gdb)",
instead of a regexp, "\(top-gdb\)" (expressed as "\\(top-gdb\\)" in TCL).
I then discovered that in order to restore the prompt gdb passes the
original value of $gdb_prompt to "set prompt", which works because
"set prompt \(gdb\) " is equivalent to "set prompt (gdb) ".
Perhaps I'm being overly cautious but this feels a bit subtle,
but at any rate as an API choice I'd much rather pass the plain text
form to with_gdb_prompt.
I also discovered that the initial value of gdb_prompt is set in
two places to two different values.
At the global level gdb.exp sets it to "\[(\]gdb\[)\]"
and default_gdb_init sets it to "\\(gdb\\)".
The former form is undesirable as an argument to "set prompt",
but it's not clear to me that just deleting this code won't break
anything. Thus I just changed the value to be consistent and added
a comment.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_prompt): Add comment and change initial value to
be consistent with what default_gdb_init uses.
(with_gdb_prompt): Change form of PROMPT argument from a regexp to
the plain text of the prompt. Add some logging printfs.
* gdb.perf/disassemble.exp: Update call to with_gdb_prompt.
See:
https://sourceware.org/ml/gdb-patches/2014-09/msg00404.html
We have a number of places that do gdb_run_cmd followed by gdb_expect,
when it would be better to use gdb_test_multiple or gdb_test.
This converts all that "grep gdb_run_cmd -A 2 | grep gdb_expect"
found.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/testsuite/
2014-09-12 Pedro Alves <palves@redhat.com>
* gdb.arch/gdb1558.exp: Replace uses of gdb_expect after
gdb_run_cmd with gdb_test_multiple or gdb_test throughout.
* gdb.arch/i386-size-overlap.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
* gdb.arch/i386-unwind.exp: Likewise.
* gdb.base/a2-run.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/chng-syms.exp: Likewise.
* gdb.base/commands.exp: Likewise.
* gdb.base/dbx.exp: Likewise.
* gdb.base/find.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/jit-simple.exp: Likewise.
* gdb.base/reread.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/step-bt.exp: Likewise.
* gdb.cp/mb-inline.exp: Likewise.
* gdb.cp/mb-templates.exp: Likewise.
* gdb.objc/basicclass.exp: Likewise.
* gdb.threads/killed.exp: Likewise.
The IRIX support wants to set a breakpoint to be hit when the startup
phase is complete, which is where shared libraries have been mapped
in. AFAIU, for most IRIX ports, that location is the entry point.
For MIPS IRIX however, GDB needs to set a breakpoint earlier, in
__dbx_link, as explained by:
#ifdef SYS_syssgi
/* On mips-irix, we need to stop the inferior early enough during
the startup phase in order to be able to load the shared library
symbols and insert the breakpoints that are located in these shared
libraries. Stopping at the program entry point is not good enough
because the -init code is executed before the execution reaches
that point.
So what we need to do is to insert a breakpoint in the runtime
loader (rld), more precisely in __dbx_link(). This procedure is
called by rld once all shared libraries have been mapped, but before
the -init code is executed. Unfortuantely, this is not straightforward,
as rld is not part of the executable we are running, and thus we need
the inferior to run until rld itself has been mapped in memory.
For this, we trace all syssgi() syscall exit events. Each time
we detect such an event, we iterate over each text memory maps,
get its associated fd, and scan the symbol table for __dbx_link().
When found, we know that rld has been mapped, and that we can insert
the breakpoint at the symbol address. Once the dbx_link() breakpoint
has been inserted, the syssgi() notifications are no longer necessary,
so they should be canceled. */
proc_trace_syscalls_1 (pi, SYS_syssgi, PR_SYSEXIT, FLAG_SET, 0);
#endif
The loop in irix_solib_create_inferior_hook then runs until whichever
breakpoint is hit first, the one set by solib-irix.c or the one set by
procfs.c.
Note the comment in disable_break talks about __dbx_init, but I think
that's a typo for __dbx_link:
- /* Note that it is possible that we have stopped at a location that
- is different from the location where we inserted our breakpoint.
- On mips-irix, we can actually land in __dbx_init(), so we should
- not check the PC against our breakpoint address here. See procfs.c
- for more details. */
This looks very much like referring to the loop in
irix_solib_create_inferior_hook stopping at __dbx_link instead of at
the entry point.
What this patch does is convert these deprecated raw breakpoints to
standard solib_event breakpoints. When the first solib-event
breakpoint is hit, we delete all solib-event breakpoints. We do that
in the so_ops->handle_event hook.
This allows getting rid of the loop in irix_solib_create_inferior_hook
completely, which should allow properly handling signals and other
events in the early startup phase, like in SVR4.
Built on x86_64 Fedora 20 with --enable-targets=all (builds
solib-irix.c).
Joel tested that with an earlier version of this patch "info shared"
after starting a program gave the same list of shared libraries as
before.
gdb/ChangeLog:
2014-09-12 Pedro Alves <palves@redhat.com>
* breakpoint.c (remove_solib_event_breakpoints_at_next_stop)
(create_and_insert_solib_event_breakpoint): New functions.
* breakpoint.h (create_and_insert_solib_event_breakpoint)
(remove_solib_event_breakpoints_at_next_stop): New declarations.
* procfs.c (dbx_link_bpt_addr, dbx_link_bpt): Delete globals.
(remove_dbx_link_breakpoint): Delete function.
(insert_dbx_link_bpt_in_file): Use
create_and_insert_solib_event_breakpoint instead of
deprecated_insert_raw_breakpoint.
(procfs_wait): Don't check whether we hit __dbx_link here.
(procfs_mourn_inferior): Don't delete the __dbx_link breakpoint
here.
* solib-irix.c (base_breakpoint): Delete global.
(disable_break): Delete function.
(enable_break): Use create_solib_event_breakpoint
instead of deprecated_insert_raw_breakpoint.
(irix_solib_handle_event): New function.
(irix_solib_create_inferior_hook): Don't run the target or disable
the mapping-complete breakpoint here.
(_initialize_irix_solib): Install irix_solib_handle_event as
so_ops->handle_event hook.
The problem is that rs6000_frame_cache attempts to read the stack backchain via
read_memory_unsigned_integer, which throws an exception if the stack pointer is
invalid. With this patch, it calls safe_read_memory_integer instead, which
doesn't throw an exception and allows for safe handling of that situation.
gdb/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/17379
* rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer
instead of read_memory_unsigned_integer.
gdb/testcase/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
PR tdep/17379
* gdb.arch/powerpc-stackless.S: New file.
* gdb.arch/powerpc-stackless.exp: New file.
I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.
But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].
gdb/testsuite/ChangeLog
2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/attach.c: Include unistd.h.
(main): Call alarm. Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.
This commit makes linux-waitpid.c include common-defs.h. GDB's
inclusion of defs.h is removed, but gdbserver's inclusion of
server.h remains to support some gdbserver-specific debug code
that cannot presently be merged. A new FIXME documents this.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include common-defs.h.
[GDBSERVER]: Add FIXME comment.
[!GDBSERVER]: Don't include defs.h or signal.h.
(linux_debug) [!GDBSERVER]: Remove empty block.
This commit makes nat/x86-dregs.c include common-defs.h rather than
defs.h or server.h. An extra header required including in order to
support this change.
gdb/ChangeLog:
* nat/x86-dregs.c: Include common-defs.h and break-common.h.
Don't include defs.h or server.h.
This commit makes nat/linux-btrace.c include common-defs.h rather
than defs.h or server.h. A couple of minor changes were required
to support this change.
gdb/ChangeLog:
* nat/linux-btrace.c: Include common-defs.h.
Don't include defs.h, server.h or gdbthread.h.
* nat/linux-btrace.h (struct target_ops): New forward declaration.
This commit makes 19 of the 22 shared .c files in common, nat and
target include common-defs.h instead of defs.h/server.h. The
remaining three files need slight extra work and are dealt with
in separate commits.
gdb/ChangeLog:
* common/agent.c: Include common-defs.h.
Don't include defs.h or server.h.
* common/buffer.c: Likewise.
* common/common-debug.c: Likewise.
* common/common-utils.c: Likewise.
* common/errors.c: Likewise.
* common/filestuff.c: Likewise.
* common/format.c: Likewise.
* common/gdb_vecs.c: Likewise.
* common/print-utils.c: Likewise.
* common/ptid.c: Likewise.
* common/rsp-low.c: Likewise.
* common/signals.c: Likewise.
* common/vec.c: Likewise.
* common/xml-utils.c: Likewise.
* nat/linux-osdata.c: Likewise.
* nat/linux-procfs.c: Likewise.
* nat/linux-ptrace.c: Likewise.
* nat/mips-linux-watch.c: Likewise.
* target/waitstatus.c: Likewise.
This introduces common-regcache.h. This contains two functions that
allow nat/linux-btrace.c to be simplified. A better long term
solution would be unify the regcache code, but this is sufficient for
now.
gdb/ChangeLog:
* common/common-regcache.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/common-regcache.h.
* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.
* nat/linux-btrace.c: Don't include regcache.h.
Include common-regcache.h.
(perf_event_read_bts): Use get_thread_regcache_for_ptid.
gdb/gdbserver/ChangeLog:
* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.
gdb/
* regcache.h (struct regset): Declare.
Commit 0b3092721e added uses of struct regset to
gdb/regcache.h, but that struct is not declared in this file, and, as it
happens, also nowhere else in the #include chain on x86 GNU/Hurd. This results
in warnings/errors such as:
gcc-4.8 [...] ../../W._C._Handy/gdb/gdb.c
In file included from ./nm.h:25:0,
from ../../W._C._Handy/gdb/defs.h:454,
from ../../W._C._Handy/gdb/gdb.c:19:
../../W._C._Handy/gdb/regcache.h:190:9: warning: 'struct regset' declared inside parameter list [enabled by default]
size_t size);
^
../../W._C._Handy/gdb/regcache.h:190:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
../../W._C._Handy/gdb/regcache.h:193:10: warning: 'struct regset' declared inside parameter list [enabled by default]
int regnum, void *buf, size_t size);
^
Doing:
gdb --pid=PID -ex run
Results in GDB getting a SIGTTIN, and thus ending stopped. That's
usually indicative of a missing target_terminal_ours call.
E.g., from the PR:
$ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
[1] 28263
[1] Killed sleep 1h
[2]+ Stopped gdb -batch sleep $p -ex run
The workaround is doing:
gdb -ex "attach $PID" -ex "run"
instead of
gdb [-p] $PID -ex "run"
With the former, gdb waits for the attach command to complete before
moving on to the "run" command, because the interpreter is in sync
mode at this point, within execute_command. But for the latter,
attach_command is called directly from captured_main, and thus misses
that waiting. IOW, "run" is running before the attach continuation
has run, before the program stops and attach completes. The broken
terminal settings are just one symptom of that. Any command that
queries or requires input results in the same.
The fix is to wait in catch_command_errors (which is specific to
main.c nowadays), just like we wait in execute_command.
gdb/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* main.c: Include "infrun.h".
(catch_command_errors, catch_command_errors_const): Wait for the
foreground command to complete.
* top.c (maybe_wait_sync_command_done): New function, factored out
from ...
(maybe_wait_sync_command_done): ... here.
* top.h (maybe_wait_sync_command_done): New declaration.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
* gdb.base/attach.exp (test_command_line_attach_run): New
procedure.
(top level): Call it.
Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin. This is in order to have GDB attach to the spawned program.
This refactors all that to a common procedure.
(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
This introduces common/symbol.h. This file declares a function that
the shared code can use and that the clients must implement. It also
changes some shared code to use these functions.
gdb/ChangeLog:
* common/symbol.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/symbol.h.
* minsyms.c (find_minimal_symbol_address): New function.
* common/agent.c: Include common/symbol.h.
[!GDBSERVER]: Don't include objfiles.h.
(agent_look_up_symbols): Use find_minimal_symbol_address.
gdb/gdbserver/ChangeLog:
* symbol.c: New file.
* Makefile.in (SFILES): Add symbol.c.
(OBS): Add symbol.o.
This commit introduces two new functions to stop and restart target
processes that shared code can use and that clients must implement.
It also changes some shared code to use these functions.
gdb/ChangeLog:
* target/target.h (target_stop_ptid, target_continue_ptid):
Declare.
* target.c (target_stop_ptid, target_continue_ptid): New
functions.
* common/agent.c [!GDBSERVER]: Don't include infrun.h.
(agent_run_command): Always use target_stop_ptid and
target_continue_ptid.
gdb/gdbserver/ChangeLog:
* target.c (target_stop_ptid, target_continue_ptid): New
functions.
This introduces target/target.h. This file declares some functions
that the shared code can use and that clients must implement. It also
changes some shared code to use these functions.
gdb/ChangeLog:
* target/target.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add target/target.h.
* target.h: Include target/target.h.
(target_read_memory, target_write_memory): Don't declare.
* target.c (target_read_uint32): New function.
* common/agent.c: Include target/target.h.
[!GDBSERVER]: Don't include target.h.
(helper_thread_id): Type changed to uint32_t.
(agent_get_helper_thread_id): Use target_read_uint32.
(agent_run_command): Always use target_read_memory and
target_write_memory.
(agent_capability): Type changed to uint32_t.
(agent_capability_check): Use target_read_uint32.
gdb/gdbserver/ChangeLog:
* target.h: Include target/target.h.
* target.c (target_read_memory, target_read_uint32)
(target_write_memory): New functions.
This commit adds a new global flag show_debug_regs to common-debug.h
to replace the flag debug_hw_points used by gdbserver and by the
Linux x86 and AArch64 ports, and to replace the flag maint_show_dr
used by the Linux MIPS port.
Note that some debug printing in the AArch64 port was enabled only if
debug_hw_points > 1 but no way to set debug_hw_points to values other
than 0 and 1 was provided; that code was effectively dead. This
commit enables all debug printing if show_debug_regs is nonzero, so
the AArch64 output will be more verbose than previously.
gdb/ChangeLog:
* common/common-debug.h (show_debug_regs): Declare.
* common/common-debug.c (show_debug_regs): Define.
* aarch64-linux-nat.c (debug_hw_points): Don't define. Replace
all uses with show_debug_regs. Replace all uses that considered
debug_hw_points as a multi-value integer with straight boolean
uses.
* x86-nat.c (debug_hw_points): Don't define. Replace all uses
with show_debug_regs.
* nat/x86-dregs.c (debug_hw_points): Don't declare. Replace
all uses with show_debug_regs.
* mips-linux-nat.c (maint_show_dr): Don't define. Replace all
uses with show_debug_regs.
gdb/gdbserver/ChangeLog:
* server.h (debug_hw_points): Don't declare.
* server.c (debug_hw_points): Don't define. Replace all uses
with show_debug_regs.
* linux-aarch64-low.c (debug_hw_points): Don't define. Replace
all uses with show_debug_regs.
This fixes two FAIL results on this testcase which were caused by a
misplaced "continue" command. This testcase used to end inferior's
execution too soon, causing the following tests to fail. Now we break
right after inferior's loop and perform the rest of the tests there.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-element.exp: Remove unexpected "continue"
command in testcase. Simplify testcase.
Since the last change to address_from_register, it no longer supports
targets that require a special conversion (gdbarch_convert_register_p)
for plain pointer type; I had assumed no target does so.
This turned out to be incorrect: MIPS64 n32 big-endian needs such a
conversion in order to properly sign-extend pointer values.
This patch fixes this regression by handling targets that need a
special conversion in address_from_register as well.
gdb/ChangeLog:
* findvar.c (address_from_register): Handle targets requiring
a special conversion routine even for plain pointer types.
Old AIX versions required GDB to update the stack pointer register and
execute at least one instruction before accessing the space newly allocated
on the user stack. This was done using the exec_one_dummy_insn routine
in rs6000-nat.c
However, in currently supported AIX versions (tested on AIX 6.1), this hack
is no longer necessary. In fact, removing the hack actually fixed several
test case failures, and removes a call to deprecated_insert_raw_breakpoint.
gdb/ChangeLog:
* rs6000-nat.c (exec_one_dummy_insn): Remove.
(store_register): Do not call exec_one_dummy_insn.
Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:
(gdb) p foo.three_ptr.all'first
Location address is not set.
(gdb) p foo.three_ptr.all'length
Location address is not set.
This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type. The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.
Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:
(gdb) p foo.three_ptr'first
Location address is not set.
(gdb) p foo.three_ptr'length
Location address is not set.
This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.
This patch fixes both issues, thus allowing us to get the expected output:
(gdb) p foo.three_ptr.all'first
$1 = 1
(gdb) p foo.three_ptr.all'length
$2 = 3
(gdb) p foo.three_ptr'first
$3 = 1
(gdb) p foo.three_ptr'length
$4 = 3
gdb/ChangeLog:
* ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
dereference it first. Use value_enclosing_type instead of
value_type.
(ada_array_length): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is now able to correctly print the entire array, but not one
element of the array. Eg:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
(gdb) p foo.three_ptr.all(1)
Cannot access memory at address 0xfffffffff4123a0c
The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.
This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
Adjust function implementation and documentation accordingly.
(ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
Update call to ada_value_ptr_subscript.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
Consider the following declaration:
type Array_Type is array (Natural range <>) of Integer;
type Array_Ptr is access all Array_Type;
for Array_Ptr'Size use 64;
Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);
This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is currently printing the value of the array incorrectly:
(gdb) p foo.three_ptr.all
$1 = (26629472 => 1, 2,
value.c:819: internal-error: value_contents_bits_eq: [...]
The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.
The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.
After fixing this issue, the debugger now correctly prints:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use VAL's enclosing type
instead of VAL's type.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
gdb/ChangeLog:
* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): Pass guile version as
last parameter to pkg-config, not first.
* configure.ac: Pass --with-guile provided pkg-config path to
GDB_GUILE_PROGRAM_NAMES.
* configure: Regenerate.
There are `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' sections
also present in Linux executables, so we can't infer IRIX OS ABI solely
from the existence of these sections. This is not going to be a problem
as there are bound to be other sections whose names start with `.MIPS.'
in IRIX executables and this selection only matters for a non-default OS
ABI in a multiple-target GDB executable. As a last resort the automatic
selection can be overridden with `set osabi'.
* mips-irix-tdep.c (mips_irix_elf_osabi_sniff_abi_tag_sections):
Exclude `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' from
the list of sections determining GDB_OSABI_IRIX.
Similarly to the previous changes to gdb.reverse/sigall-reverse.exp and
gdb.reverse/until-precsave.exp this corrects the timeout tweak in
gdb.base/watchpoint-solib.exp.
This test case executes a large amount of code with a software watchpoint
enabled. This means single-stepping all the way through and takes a lot
of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 714
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 1275
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 115
(values in seconds) -- all of which having the default timeout of 60s,
set based on the requirement of the remaining test cases (other than
gdb.reverse ones).
Here again the timeout extension to have a meaning should be calculated
by scaling rather than using an arbitrary constant, and a larger factor
of 30 will do, leaving some margin. Hopefully for everyone or otherwise
we'll probably have to come up with a smarter solution.
OTOH the other test cases in this script do not require the extension so
they can be moved outside its umbrella so as to avoid unnecessary delays
if something goes wrong and a genuine timeout triggers.
* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
of 30 rather than hardcoding 120 for a slow test case. Take the
`gdb,timeout' target setting into account for this calculation.
Don't extend the timeout for the test cases that don't need it.
There are three cases in two scripts in the gdb.reverse subset that
take a particularly long time. Two of them are already attempted to
take care of by extending the timeout from the default. The remaining
one has no precautions taken. The timeout extension is ineffective
though, it is done by adding a constant rather than by scaling and as
a result while it may work for target boards that get satisfied with
the detault test timeout of 10s, it does not serve its purpose for
slower ones.
Here are indicative samples of execution times (in seconds) observed
for these cases respectively, for an ARMv7 Panda board running Linux
and a `-march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 385
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4440
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 965
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 465
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4191
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 669
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 45
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 433
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 104
Based on the performance of other tests these two test configurations
have their default timeout set to 450s and 60s respectively.
The remaining two multilibs (`-mthumb -march=armv4t' and `-mthumb
-march=armv7-a') do not produce test results usable enough to have data
available for these cases.
Based on these results I have tweaked timeouts for these cases as
follows. This, together with a suitable board timeout setting, removes
timeouts for these cases. Note that for the default timeout of 10s the
new setting for the first case in gdb.reverse/until-precsave.exp is
compatible with the old one, just a bit higher to keep the convention
of longer timeouts to remain multiples of 30s. The second case there
does not need such a high setting so I have lowered it a bit to avoid
an unnecessary delay where this test case genuinely times out.
* gdb.reverse/sigall-reverse.exp: Increase the timeout by
a factor of 2 for a slow test case. Take the `gdb,timeout'
target setting into account for this calculation.
* gdb.reverse/until-precsave.exp: Increase the timeout by
a factor of 15 and 3 respectively rather than adding 120
for a pair of slow test cases. Take the `gdb,timeout'
target setting into account for this calculation.
The recent change to introduce `gdb_reverse_timeout' turned out
ineffective for board setups that set the `gdb,timeout' target variable.
A lower `gdb,timeout' setting takes precedence and defeats the effect of
`gdb_reverse_timeout'. This is because the global timeout is overridden
in gdb_test_multiple and then again in gdb_expect.
Three timeout variables are taken into account in these two places, in
this precedence:
1. The `gdb,timeout' target variable.
2. The caller's local `timeout' variable (upvar timeout)
3. The global `timeout' variable.
This precedence is obeyed by gdb_test_multiple strictly. OTOH
gdb_expect will select the higher of the two formers and will only take
the latter into account if none of the formers is present. However the
two timeout selections are conceptually the same and gdb_test_multiple
does its only for the purpose of passing it down to gdb_expect.
Therefore I decided there is no point to keep carrying on this
duplication and removed the sequence from gdb_test_multiple, however
retaining the `upvar timeout' variable definition. This way gdb_expect
will still access gdb_test_multiple's caller `timeout' variable (if any)
via its own `upvar timeout' reference.
Now as to the sequence in gdb_expect. In addition to the three
variables described above it also takes a timeout argument into account,
as the fourth value to choose from. It is currently used if it is
higher than the timeout selected from the variables as described above.
With the timeout selection code from gdb_test_multiple gone, gone is
also the most prominent use of this timeout argument, it's now used in
a couple of places only, mostly within this test framework library code
itself for preparatory commands or suchlike. With this being the case
this timeout selection code can be simplified as follows:
1. Among the three timeout variables, the highest is always chosen.
This is so that a test case doesn't inadvertently lower a high value
timeout needed by slow target boards. This is what all test cases
use.
2. Any timeout argument takes precedence. This is for special cases
such as within the framework library code, e.g. it doesn't make sense
to send `set height 0' with a timeout of 7200 seconds. This is a
local command that does not interact with the target and setting a
high timeout here only risks a test suite run taking ages if it goes
astray for some reason.
3. The fallback timeout of 60s remains.
* lib/gdb.exp (gdb_test_multiple): Remove code to select the
timeout, don't pass one down to gdb_expect.
(gdb_expect): Rework timeout selection.
The trad_frame_set_reg_unknown declaration was added in commit
0db9b4b709 (March 2004), but apparently never defined or referenced.
gdb/ChangeLog:
* trad-frame.h (trad_frame_set_reg_unknown): Remove declaration.
As it happens we have a board that fails a gdb.base/gcore-relro.exp
test case reproducibly and moreover the case appears to trigger a
kernel bug making the it less than usable. Specifically the board
remains responsive to some extent, however processes do not appear
to be able to successfully complete termination anymore and perhaps
more importantly further gdbserver processes can be started, but they
never reach the stage of listening on the RSP socket.
This change handles timeouts in gdbserver start properly, by throwing
a TCL error exception when gdbserver does not report listening on the
RSP socket in time. This is then caught at the outer level and
reported, and 2 rather than 1 is returned so that the caller may tell
the failure to start gdbserver and other issues apart and act
accordingly (or do nothing).
I thought letting the exception unwind further on might be a good idea
for any test harnesses out there to break outright where a gdbserver
start error is silently ignored right now, however I figured out the
calls to gdbserver-support.exp are buried down too deep in the GDB test
suite for such a change to be made easily. I think returning a distinct
return value is good enough (the API says "non-zero", so 2 is as good as
1) and we can always make the error harder in a later step if required.
With config/gdbserver.exp being used this change remains transparent
to the target board, the return value is passed up by gdb_reload and
the error exception unwinds through gdbserver_gdb_load and is caught
and handled by mi_gdb_target_load. A call to perror is still made,
reporting the timeout, and in the case of mi_gdb_target_load the
procedure returns a value denoting unsuccessful completion. An
unsuccessful completion of gdb_reload is already handled elsewhere.
An alternative gdbserver board configuration can interpret the return
value in its gdb_reload implementation and catch the error in
gdbserver_gdb_load in an attempt to recover a target board that has
gone astray, for example by rebooting the board somehow. This has
proved effective with our failing board, that now completes the
remaining test cases with no further hiccups.
* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.
Gdbserver support code uses the global timeout value to determine when
to stop waiting for a gdbserver process being started to respond before
continuing anyway. This timeout is usually as low as 10s and may not
be enough in this context, for example on the first run where the
filesystem cache is cold, even if it is elsewhere.
E.g. I observe this reliably with gdbserver started the first time in
QEMU running in the system emulation mode:
(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main
-- notice how the test harness proceeded with the `target remote ...'
command even though gdbserver hasn't completed its startup yet. A
while later when it's finally ready it's too late already. I checked
the timing here and it takes gdbserver roughly 25 seconds to start in
this scenario. Subsequent gdbserver starts in the same test run take
less time and usually complete within 10 seconds although occasionally
`target remote ...' precedes the corresponding `Listening on port...'
message again.
Therefore I have fixed this problem by setting an explicit timeout to
120s on the expect call in question. If this turns out too arbitrary
sometime, then perhaps a separate `gdbserver_timeout' setting might be
due.
* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.
The following patch...
commit 3116063bd6
Date: Fri Jun 27 09:52:29 2014 +0100
Subject: Tidy #include lists
... introduced a build failure on certain x86 GNU/Linux distributions
(reproduced on SuSE 10 and RHES4) due to "struct iovec" not being
defined. This struct is defined in <sys/uio.h>, which used to be
explicitly included, but no longer is after the commit above was
applied.
[...]/i386-linux-nat.c: In function 'fetch_xstateregs':
[...]/i386-linux-nat.c:325:16: error: storage size of 'iov' isn't known
[...]/i386-linux-nat.c: In function 'store_xstateregs':
[...]/i386-linux-nat.c:348:16: error: storage size of 'iov' isn't known
make[2]: *** [i386-linux-nat.o] Error 1
It seems to be working on newer GNU/Linux distros thanks to indirect
inclusion of <sys/uio.h>, but it does not work on some other versions
of the same distros. This is why indirect includes of public APIs
should be avoided if at all possible.
This patch fixes the issue by adding the explicit include back.
gdb/ChangeLog:
* i386-linux-nat.c, x86-linux-nat.c: Add <sys/uio.h> #include.
The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered. The other thread
will see the signal and the sigsuspend won't "wake up".
Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.
gdb/ChangeLog:
PR 17247
* guile.c: #include <signal.h>.
(_initialize_guile): Block SIGCHLD while initializing Guile.
Replaces the following, which is reverted.
2014-07-26 Doug Evans <xdje42@gmail.com>
PR 17185
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
gdb/ChangeLog:
* guile/scm-cmd.c (gdbscm_parse_command_name): Replace magic number
with named constant. Fix style of pointer comparison.
* python/py-cmd.c (gdbpy_parse_command_name): Ditto.
Hi,
I see the following fail on arm-none-eabi target,
-var-evaluate-expression -f nat foo^M
^done,value="0x3 <_ftext+2>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: eval variable -f nat foo
the "<_ftext+2>" isn't expected in the test, so "set print symbol off"
can prevent printing it. It is obvious and I'll commit it in three
days if no comments.
gdb/testsuite:
2014-09-09 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-display.exp: Set print symbol off.
This patch fixes the routines to collect and supply ptrace registers on ppc64le
gdbserver. Originally written for big endian arch, they were causing several
issues on little endian. With this fix, the number of unexpected failures in
the testsuite dropped from 263 to 72 on ppc64le.
gdb/gdbserver/ChangeLog
* linux-ppc-low.c (ppc_collect_ptrace_register): Adjust routine to take
endianness into account.
(ppc_supply_ptrace_register): Likewise.
have empty bodies.
User-defined commands that have empty bodies weren't being shown because
the print function returned too soon. Now, it prints the command's name
before checking if it has any body at all. This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.
gdb/Changelog:
* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.
gdb/testsuite/Changelog:
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
https://bugzilla.redhat.com/show_bug.cgi?id=1126177
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
#0 0x992bee in value_type .../gdb/value.c:925
#1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
#2 0x87cfae in enumerate_args python/py-framefilter.c:596
#3 0x87e0b0 in py_print_args python/py-framefilter.c:968
It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.
Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.
It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.
gdb/ChangeLog
PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.
gdb/testsuite/ChangeLog
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
This patch is a fix to PR gdb/17235. The bug is about an unused
variable that got declared and set during one of the parsing phases of
an SDT probe's argument. I took the opportunity to rewrite some of the
code to improve the parsing. The bug was actually a thinko, because
what I wanted to do in the code was to discard the number on the string
being parsed.
During this portion, the code identifies that it is dealing with an
expression that begins with a sign ('+', '-' or '~'). This means that
the expression could be:
- a numeric literal (e.g., '+5')
- a register displacement (e.g., '-4(%rsp)')
- a subexpression (e.g., '-(2*3)')
So, after saving the sign and moving forward 1 char, now the code needs
to know if there is a digit followed by a register displacement prefix
operand (e.g., '(' on x86_64). If yes, then it is a register
operation. If not, then it will be handled recursively, and the code
will later apply the requested operation on the result (either a '+', a
'-' or a '~').
With the bug, the code was correctly discarding the digit (though using
strtol unnecessarily), but it wasn't properly dealing with
subexpressions when the register indirection prefix was '(', like on
x86_64. This patch also fixes this bug, and includes a testcase. It
passes on x86_64 Fedora 20.
valgrind caught that parse_number reads uninitialized memory when we
parse literal "0":
$ valgrind ./gdb -q -nx -ex "set height 0"
(...)
==10378== Conditional jump or move depends on uninitialised value(s)
==10378== at 0x548A10: parse_number (c-exp.y:1828)
==10378== by 0x54A340: lex_one_token (c-exp.y:2638)
==10378== by 0x54B4BB: c_lex (c-exp.y:3089)
==10378== by 0x544951: c_parse_internal (c-exp.c:2208)
==10378== by 0x54BF8C: c_parse (c-exp.y:3260)
==10378== by 0x6502E7: parse_exp_in_context_1 (parse.c:1221)
==10378== by 0x650064: parse_exp_in_context (parse.c:1122)
==10378== by 0x65001F: parse_exp_1 (parse.c:1114)
==10378== by 0x650421: parse_expression (parse.c:1266)
==10378== by 0x5A74B7: parse_and_eval_long (eval.c:92)
==10378== by 0x501ABD: do_set_command (cli-setshow.c:302)
==10378== by 0x721059: execute_command (top.c:452)
==10378==
(gdb)
I've pushed the obvious fix.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
* c-exp.y (parse_number): Skip handling base-switching prefixes if
the input is only one character long.
This commit fixes the PR mentioned in $subject. It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.
This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario. I am sending
a testcase which triggers this error as well.
gdb/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* f-valprint.c (f_val_print): Specify the correct print option to
use when printing integer values.
gdb/testsuite/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.
Historically the Linux x86 watchpoint code did not cope with multi-
threaded processes and LWP IDs were passed to it wrapped as PIDs.
Not all entry points were converted when the Linux x86 watchpoint
code was made multi-thread-aware, so a handler was left in place to
cope with wrapped LWPs. Since then all such entry points have been
converted to pass regular LWPs and the handler is now redundant.
This commit removes the handler and adds assertions to ensure no
wrapped LWPs are passed in future.
gdb/ChangeLog:
* x86-linux-nat.c (x86_linux_dr_get, x86_linux_dr_set):
Remove code to cope with LWPs wrapped as PIDs.
Add assertions to ensure no wrapped LWPs are passed.
Git 9a0dc9e3 regressed gdb.dwarf2/pieces-optimized-out.exp, visible on
i686 (the test doesn't run on x86_64):
(gdb) p s
-$1 = {a = 5, b = <optimized out>, c = <optimized out>, d = <optimized out>}
+$1 = {a = 5, b = <optimized out>, c = 0, d = 0}
-(gdb) PASS: gdb.dwarf2/pieces-optimized-out.exp: print s
+(gdb) FAIL: gdb.dwarf2/pieces-optimized-out.exp: print s
The regression was caused by this removal in cp-valprint.c:
@@ -293,12 +293,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
{
fputs_filtered (_("<synthetic pointer>"), stream);
}
- else if (!value_bits_valid (val,
- TYPE_FIELD_BITPOS (type, i),
- TYPE_FIELD_BITSIZE (type, i)))
- {
- val_print_optimized_out (val, stream);
- }
else
{
struct value_print_options opts = *options;
The idea was that we'd just fallback to calling value_field_bitfield,
which handles unavailable values (in unpack_value_bits_as_long_1) so
should be able to handle optimized out values too. Alas, it doesn't.
This is currently a bit too messy. Instead of teaching
unpack_value_bits_as_long_1 about optimized out bits, let's bite the
bullet and teach the value code to handle partially optimized out
bitfield, by having it unpack a bitfield and then propagate the range
metadata. Turns out the resulting code looks simpler and clearer.
Tested on x86_64 Fedora 20, -m64/-m32.
gdb/ChangeLog:
* value.c (value_ranges_copy_adjusted): New function, factored out
from ...
(value_contents_copy_raw): ... here.
(unpack_value_bits_as_long_1): Rename back to ...
(unpack_bits_as_long): ... this. Remove 'original_value' and
'result' parameters. Change return type to LONGEST.
(unpack_value_bits_as_long): Delete.
(unpack_value_field_as_long_1): Delete.
(unpack_value_field_as_long, unpack_field_as_long): Reimplement.
(unpack_value_bitfield): New function.
(value_field_bitfield): Reimplement using unpack_value_bitfield.
(value_fetch_lazy): Use unpack_value_bitfield.
* value.h (unpack_value_bits_as_long): Delete declaration.
gdb/doc/ChangeLog:
* python.texi (Types In Python): Type.template_argument(n) returns a
gdb.Value or a gdb.Type and throws an exception if n is out of
range.
The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.
gdb/ChangeLog:
2014-08-29 Sasha Smundak <asmundak@google.com>
* python/py-frame.c (frapy_read_register): New function.
gdb/doc/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* python.texi (Frames in Python): Add read_register description.
gdb/testsuite/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
PTRACE_PEEKUSER can return -1, which is usually used to determine whether
a system call has reported an error, so errno must be used alone to
determine whether an error occurred. However errno isn't modified by a
successful system call so it must be reset to a known value (0) before the
syscall call.
Add the missing errno reset when reading the DSP_CONTROL register in the
native MIPS Linux backend and the MIPS gdbserver backend.
gdb/:
* mips-linux-nat.c (mips_linux_read_description): Reset errno to 0
prior to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
gdb/gdbserver/:
* linux-mips-low.c (mips_read_description): Reset errno to 0 prior
to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
The loop macro ALL_DEBUG_REGISTERS does not iterate over the status or
control registers, so its name is misleading. This commit renames it
as ALL_DEBUG_ADDRESS_REGISTERS and updates all uses. This commit also
updates its loop conditions to an equivalent but better form, and
makes two functions use it that had previously hardwired the loop.
A comment on a related field in the x86_debug_reg_state structure is
also updated to reflect that the field refers specifically to address
registers only.
gdb/ChangeLog:
* nat/x86-dregs.h (ALL_DEBUG_REGISTERS): Renamed as...
(ALL_DEBUG_ADDRESS_REGISTERS): New macro. All uses updated.
Loop conditions changed to equivalent form.
(struct x86_debug_reg_state): Updated dr_ref_count comment.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386". All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386". This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".
This commit only renames OS-independent files. The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.
gdb/ChangeLog:
* i386-nat.h: Renamed as...
* x86-nat.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
gdb/gdbserver/ChangeLog:
* i386-low.h: Renamed as...
* x86-low.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
This commit replaces two uses of xcalloc (1, ...) with XCNEW.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_linux_new_process): Use XCNEW.
(x86_linux_new_thread): Likewise.
This commit replaces the hacky "exception" system in gdbserver with
the exceptions and cleanups subsystem from GDB.
Only the catch/cleanup code in what was "main" has been updated to
use the new system. Other parts of gdbserver can now be converted
to use TRY_CATCH and cleanups on an as-needed basis.
A side-effect of this commit is that some error messages will change
slightly, and in cases with multiple errors the error messages will
be printed in a different order.
gdb/gdbserver/ChangeLog:
* server.h (setjmp.h): Do not include.
(toplevel): Do not declare.
(common-exceptions.h): Include.
(cleanups.h): Likewise.
* server.c (toplevel): Do not define.
(exit_code): New static global.
(detach_or_kill_for_exit_cleanup): New function.
(main): New function. Original main renamed to...
(captured_main): New function.
* utils.c (verror) [!IN_PROCESS_AGENT]: Use throw_verror.
Pedro Alves
Doug Evans
Iain Buclaw
Andreas Arnez
Ajit Kumar Agarwal
Siva Chandra
Yao Qi
Joel Brobecker
Maciej W. Rozycki
Sergio Durigan Junior
Jan Kratochvil
Ajit Kumar Agarwal
Stan Shebs
Gary Benson
Luis Machado
Pierre Muller
Simon Marchi
Don Breazeal
James Hogan
Jan-Benedict Glaw
Ulrich Weigand
Patrick Palka
Samuel Thibault
Omair Javaid
Doug Evans
Edjunior Barbosa Machado
Thomas Schwinge
Gabriel Krisman Bertazi
Justin Lebar
Sasha Smundak