I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
I see the following fail in some thumb multi-lib in arm-none-linux-gnueabi,
info function jit_function^M
All functions matching regular expression "jit_function":^M
^M
Non-debugging symbols:^M
0x00000790 __real_jit_function_XXXX^M
0x0000079c __jit_function_XXXX_from_arm^M
0x0000079c jit_function_0000^M
0x00000790 __real_jit_function_XXXX^M
0x0000079c __jit_function_XXXX_from_arm^M
0x0000079c jit_function_0001^M
(gdb) FAIL: gdb.base/jit.exp: one_jit_test-2: info function jit_function
the test expects to see only jit_function_0000 and jit_function_0001
one_jit_test 2 "${hex} jit_function_0000\[\r\n\]+${hex} jit_function_0001"
Symbols with the prefix "__real_" or suffix "_from_arm" is generated
by gcc/ld for arm/thumb interworking.
This patch is to restrict the pattern from "jit_function" to
"^jit_function", the output becomes expected.
gdb/testsuite:
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/jit.exp (one_jit_test): Restrict the pattern
from "jit_function" to "^jit_function".
I see two fails in async.exp on arm-none-eabi target:
nexti&^M
(gdb) 0x000001ba 14 x = 5; x = 5;^M
completed.^M
FAIL: gdb.base/async.exp: nexti&
finish&^M
Run till exit from #0 0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M
(gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M
32 y = foo ();^M
Value returned is $1 = 8^M
completed.^M
FAIL: gdb.base/async.exp: finish&
The corresponding test is "test_background "nexti&" "" ".*y = 3.*"",
and it assumes that GDB "nexti" into the next source line. It is wrong
on arm. After "nexti", it still stops at the same source line, and it
fails.
When gdb does "finish", if the PC is in the middle of a source line,
the PC address is printed too. See stack.c:print_frame,
if (opts.addressprint)
if (!sal.symtab
|| frame_show_address (frame, sal)
|| print_what == LOC_AND_ADDRESS)
{
annotate_frame_address ();
if (pc_p)
ui_out_field_core_addr (uiout, "addr", gdbarch, pc);
else
ui_out_field_string (uiout, "addr", "<unavailable>");
annotate_frame_address_end ();
ui_out_text (uiout, " in ");
}
frame_show_address checks whether PC is the middle of a source line.
Since after "nexti", the inferior stops at the middle of a source line,
when we do "finish" the PC address is displayed.
In sum, GDB works well, but test case needs update. This patch is to
add a statement at the same line to make sure "nexti" doesn't go to
the new line, match the next instruction address in the output and
match the hex address the output of "finish".
gdb/testsuite:
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/async.c (foo): Add one statement.
* gdb.base/async.exp: Get the next instruction address and
match the output of "nexti" by instruction address. Match
the hex address in the output of "finish".
The six signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM
are ANSI-standard and thus guaranteed to be available. This patch
removes all preprocessor conditionals relating to these symbols.
gdb/
2014-06-06 Gary Benson <gbenson@redhat.com>
* common/signals.c: Remove preprocessor conditionals for
always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE,
SIGSEGV and SIGTERM.
* proc-events.c: Likewise.
gdb/testsuite/
2014-06-06 Gary Benson <gbenson@redhat.com>
* gdb.base/call-signals.c: Remove preprocessor conditionals
for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE,
SIGSEGV and SIGTERM.
* gdb.base/sigall.c: Likewise.
* gdb.base/unwindonsignal.c: Likewise.
* gdb.reverse/sigall-reverse.c: Likewise.
hbreak-unmapped.exp assumes that memory at address 0 is unmapped or
unreadable, but on bare metal or uclinux targets, memory at address
0 is readable. For example, on arm-none-eabi, the vector table base
address is 0x0.
hbreak *0^M
Hardware assisted breakpoint 3 at 0x0: file
/scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S,
line 25.^M
(gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0
info break^M
Num Type Disp Enb Address What^M
3 hw breakpoint keep y 0x00000000
/scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M
(gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint
delete $bpnum
This patch is to check whether address 0 is readable via command 'x 0'.
If it is, skip the test.
gdb/testsuite:
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/hbreak-unmapped.exp: Read memory at address 0. If
readable, skip the test.
Target sections added by the add-symbol-file-from-memory command are not
removed when the process exits. In fact, they are not removed, at all.
This causes GDB to crash in gdb.base/break-interp.exp.
Change the owner of those target sections to the object file generated in
symbol_file_add_from_memory and generalize the free_objfile observer in
symfile.c to remove target sections of any freed object file.
The code in gdb.threads/staticthreads.exp about checking the value of
tlsvar in main thread is racy, because when child thread hits
breakpoint, the main thread may not go into pthread_join yet, and
may not be unwind to main.
This patch is to move the line setting breakpoint on after sem_wait,
so that the child thread will hit breakpoint after main thread calls
sem_post. IOW, when child thread hits breakpoint, the main thread is
in either sem_post or pthread_join. "up 10" can unwind main thread to
main.
gdb/testsuite:
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.threads/staticthreads.c (thread_function): Move the line
setting breakpoint on forward.
* gdb.threads/staticthreads.exp: Update comments.
Original patch:
https://sourceware.org/ml/gdb-patches/2014-04/msg00552.html
New in v2:
* In remote.c:escape_buffer, pass '\\' to fputstrn_unfiltered/printchar to
make sure backslashes are escaped in remote debug output.
* Updated function documentation for printchar.
See updated ChangeLog below.
--------------------
The quoting in whatever goes in the event_channel of MI is little bit broken.
Link for the lazy:
https://sourceware.org/bugzilla/show_bug.cgi?id=15806
Here is an example of a =library-loaded event with an ill-named directory,
/tmp/how"are\you (the problem is present with every directory on Windows since
it uses backslashes as a path separator). The result will be the following:
=library-loaded,id="/tmp/how"are\\you/libexpat.so.1",...
The " between 'how' and 'are' should be escaped.
Another bad behavior is double escaping in =breakpoint-created, for example:
=breakpoint-created,bkpt={...,fullname="/tmp/how\\"are\\\\you/test.c",...}
The two backslashes before 'how' should be one and the four before 'you' should
be two.
The reason for this is that when sending something to an MI console, escaping
can take place at two different moments (the actual escaping work is always
done in the printchar function):
1. When generating the content, if ui_out_field_* functions are used. Here,
fields are automatically quoted with " and properly escaped. At least
mi_field_string does it, not sure about mi_field_fmt, I need to investigate
further.
2. When gdb_flush is called, to send the data in the buffer of the console to
the actual output (stdout). At this point, mi_console_raw_packet takes the
whole string in the buffer, quotes it, and escapes all occurences of the
quoting character and backslashes. The event_channel does not specify a quoting
character, so quotes are not escaped here, only backslashes.
The problem with =library-loaded is that it does use fprintf_unfiltered, which
doesn't do escaping (so, no #1). When gdb_flush is called, backslashes are
escaped (#2).
The problem with =breakpoint-created is that it first uses ui_out_field_*
functions to generate its output, so backslashes and quotes are escaped there
(#1). backslashes are escaped again in #2, leading to an overdose of
backslashes.
In retrospect, there is no way escaping can be done reliably in
mi_console_raw_packet for data that is already formatted, such as
event_channel. At this point, there is no way to differentiate quotes that
delimit field values from those that should be escaped. In the case of other MI
consoles, it is ok since mi_console_raw_packet receives one big string that
should be quoted and escaped as a whole.
So, first part of the fix: for the MI channels that specify no quoting
character, no escaping at all should be done in mi_console_raw_packet (that's
the change in printchar, thanks to Yuanhui Zhang for this). For those channels,
whoever generates the content is responsible for proper quoting and escaping.
This will fix the =breakpoint-created kind of problem.
Second part of the fix is to make =library-loaded generate content that is
properly escaped. For this, we use ui_out_field_* functions, instead of one big
fprintf_unfiltered. =library-unloaded suffered from the same problem so it is
modified as well. There might be other events that need fixing too, but that's
all I found with a quick scan. Those that use fprintf_unfiltered but whose sole
variable data is a %d are not critical, since it won't generate a " or a \.
Finally, a test has been fixed, as it was expecting an erroneous output.
Otherwise, all other tests that were previously passing still pass (x86-64
linux).
gdb/ChangeLog:
2014-06-02 Simon Marchi <simon.marchi@ericsson.com>
PR mi/15806
* utils.c (printchar): Don't escape at all if quoter is NUL.
Update function documentation to clarify effect of parameter
QUOTER.
* remote.c (escape_buffer): Pass '\\' as the quoter to
fputstrn_unfiltered.
* mi/mi-interp.c (mi_solib_loaded): Use ui_out_field_* functions to
generate the output.
(mi_solib_unloaded): Same.
gdb/testsuite/ChangeLog:
2014-06-02 Simon Marchi <simon.marchi@ericsson.com>
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Fix
erroneous dprintf expected input.
The goal of this patch is to provide an easy way to make
--disable-werror the default when building binutils, or the parts
of binutils that need to get built when building GDB. In development
mode, we want to continue making -Werror the default with GCC.
But, when making releases, I think we want to make it as easy as
possible for regular users to successfully build from sources.
GDB already has this kind of feature to turn -Werror as well as
the use of the libmcheck library. As GDB Release Manager, I take
advantage of it to turn those off after having cut the branch.
I'd like to be able to do the same for the binutils bits. And
perhaps Tristan will want to do the same for his releases too
(not sure, binutils builders might be a little savvier than GDB
builders).
This patch introduces a new file, called development.sh, which
just sets a variable called $development. In our development branches
(Eg. "master"), it's set to true. But setting it to false would allow
us to change the default behavior of various development-related
features to be turned off; in this case, it turns off the use of
-Werror by default (use --enable-werror to turn it back on).
bfd/ChangeLog:
* development.sh: New file.
* warning.m4 (AM_BINUTILS_WARNINGS): Source bfd/development.sh.
Make -Werror the default with GCC only if DEVELOPMENT is true.
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add
$(srcdir)/development.sh.
* Makefile.in, configure: Regenerate.
binutils/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gas/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gold/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): New.
* Makefile.in, configure: Regenerate.
gprof/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
ld/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
opcodes/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gdb/ChangeLog:
* development.sh: Delete.
* Makefile.in (config.status): Adjust dependency on development.sh.
* configure.ac: Adjust development.sh source call.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
* configure.ac: Adjust development.sh source call.
* Makefile.in (config.status): Adjust dependency on development.sh.
* configure: Regenerate.
Tested on x86_64-linux by building two ways: One with DEVELOPMENT
set to true, and one with DEVELOPMENT set to false. In the first
case, I could see the use of -Werror, while it disappeared in
the second case.
Support for smobs as goops classes is changing in guile 2.2.
We may eventually switch to using structs instead of smobs,
so remove any claim we support goops or generics for now.
* gdb.guile/scm-generics.exp: Delete.
When debugging on LynxOS targets (and probably on SPU targets as well),
inserting a breakpoint and resuming the program's execution causes
GDBserver to crash.
The crash occurs while handling the Z0 packet sent by GDB to insert
our breakpoint, because z_type_supported calls
the_target->supports_z_point_type without checking that it is not NULL
This patch fixes the issue by making z_type_supported return false if
the_target->supports_z_point_type is NULL.
gdb/gdbserver/ChangeLog:
PR server/17023
* mem-break.c (z_type_supported): Return zero if
THE_TARGET->SUPPORTS_Z_POINT_TYPE is NULL.
Tested on ppx-lynx5.
It is valid in GNU C to have a VLA in a struct or union type, but gdb
did not handle this.
This patch adds support for these cases in the obvious way.
Built and regtested on x86-64 Fedora 20.
New tests included.
2014-06-04 Tom Tromey <tromey@redhat.com>
* ada-lang.c (ada_template_to_fixed_record_type_1): Use
value_from_contents_and_address_unresolved.
(ada_template_to_fixed_record_type_1): Likewise.
(ada_which_variant_applies): Likewise.
* value.h (value_from_contents_and_address_unresolved): Declare.
* value.c (value_from_contents_and_address_unresolved): New
function.
* gdbtypes.c (is_dynamic_type, resolve_dynamic_type)
<TYPE_CODE_STRUCT, TYPE_CODE_UNION>: New cases.
(resolve_dynamic_struct, resolve_dynamic_union): New functions.
2014-06-04 Tom Tromey <tromey@redhat.com>
* gdb.base/vla-datatypes.exp: Add tests for VLA-in-structure and
VLA-in-union.
* gdb.base/vla-datatypes.c (vla_factory): Add vla_struct,
inner_vla_struct, vla_union types. Initialize objects of those
types and compute their sizes.
I noticed that gdbtypes.c:is_dynamic_type has some unneeded "break"s.
This patch cleans up the function a bit, removing those and removing
the switch's default case so that the end of the function is a bit
clearer.
2014-06-04 Tom Tromey <tromey@redhat.com>
* gdbtypes.c (is_dynamic_type): Remove unneeded "break"s.
This constifies the "args" argument to the target_ops to_attach
method.
I updated all instances of the method. I could not compile all of
them but I hand-inspected them. In all cases either the argument is
ignored, or it is passed to parse_pid_to_attach. (linux-nat does some
extra stuff, but that one I built...)
If you want to try it on your host of choice, please do so.
The code in parse_pid_to_attach seems a little bogus to me. If there
is a platform with a broken strtoul, we have better methods for fixing
the issue now. However, I left the code as is since it is clearly ok
to do so.
Built and regtested on x86-64 Fedora 20.
2014-06-04 Tom Tromey <tromey@redhat.com>
* procfs.c (procfs_attach): Make "args" const.
* windows-nat.c (windows_attach): Make "args" const.
* nto-procfs.c (procfs_attach): Make "args" const.
* inf-ttrace.c (inf_ttrace_attach): Make "args" const.
* go32-nat.c (go32_attach): Make "args" const.
* gnu-nat.c (gnu_attach): Make "args" const.
* darwin-nat.c (darwin_attach): Make "args" const.
* inf-ptrace.c (inf_ptrace_attach): Make "args" const.
* linux-nat.c (linux_nat_attach): Make "args" const.
* remote.c (extended_remote_attach_1, extended_remote_attach):
Make "args" const.
* target.h (struct target_ops) <to_attach>: Make "args" const.
(find_default_attach): Likewise.
* utils.c (parse_pid_to_attach): Make "args" const.
* utils.h (parse_pid_to_attach): Update.
This converts to_thread_address_space to use TARGET_DEFAULT_FUNC.
This method was one of a handful not using the normal target
delegation approach. The only rationale here is consistency in the
target vector.
Built and regtested on x86-64 Fedora 20.
2014-06-04 Tom Tromey <tromey@redhat.com>
* target-delegates.c: Rebuild.
* target.c (default_thread_address_space): New function.
(target_thread_address_space): Simplify.
* target.h (struct target_ops) <to_thread_address_space>: Add
TARGET_DEFAULT_FUNC.
sss-bp-on-user-bp.c has an assumption that write to integer can be
compiled to a single instruction, which isn't true on some arch, such
as arm. This test requires setting two breakpoints on two consecutive
instructions, so this patch is to get the address of the next
instruction via disassemble and set the 2nd breakpoint there. This
approach is portable.
This patch fixes the fails in sss-bp-on-user-bp.exp on arm-none-abi
target. There is no change in x86 test results. I also revert the
patch to PR breakpoints/17000, and verified that the patched
sss-bp-on-user-bp.exp still trigger the fail on
x86-with-software-single-step.
gdb/testsuite:
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/sss-bp-on-user-bp.c (main): Remove comments.
* gdb.base/sss-bp-on-user-bp.exp: Don't set breakpoint on
"set bar break here". Get the next instruction address and
set breakpoint there. Remove "bar break" from the regexp
patterns.
Add an assert and remove an unused line of code.
bfd/ChangeLog:
2014-06-04 Will Newton <will.newton@linaro.org>
* elfnn-aarch64.c (tpoff_base): Make test of tls_sec
being non-NULL into an assert.
(elfNN_aarch64_tls_relax): Remove unused code.
This patch is update version according to the discussion in
https://www.sourceware.org/ml/gdb-patches/2009-11/msg00090.html.
If test get the target doesn't support fileio system according to the
remote log. It will set this test as "unsupported".
Before I made this patch, I want add a check before all of tests in this
file. But I found that the target maybe support one call but not others.
For example: my target support Fwrite, Fopen and so on. But not Fgettimeofday.
And it doesn't support Fsystem NULL but it support Fsystem not NULL.
So I think if we want to check target support fileio, we need check them
one by one.
2014-06-04 Nathan Sidwell <nathan@codesourcery.com>
Hui Zhu <hui@codesourcery.com>
* gdb.base/fileio.exp: Add test for shell not available as well as
available.
* gdb.base/fileio.c (test_system): Check for shell twice.
When I test gdb head (for 7.8 release) on arm-none-eabi, I find the
following this failure, which are caused by the improper regexp
pattern in the test.
(gdb) help target native^M
Undefined target command: "native". Try "help target".^M
(gdb) FAIL: gdb.base/auto-connect-native-target.exp: help target native
The space in front of "$gdb_prompt $" looks redundant, and this patch
is to remove it from the regexp pattern.
gdb/testsuite:
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/auto-connect-native-target.exp: Remove redundant
space from the regexp pattern.
I see this failure on arm-none-eabi gdb testing.
target native^M
Undefined target command: "native". Try "help target".^M
(gdb) FAIL: gdb.base/default.exp: target native
This patch is to update the regexp pattern to match "native" instead of
"child".
gdb/testsuite:
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/default.exp: Replace "child" with "native" in
regexp pattern.
A recent change broke the documentation build due to a think-o
in a reference. Fixed thusly.
gdb/doc/ChangeLog:
* python.texi (Xmethod API): Fix reference to "Progspaces In
Python".
Tested by rebuilding all documentation formats.
* NEWS (Python Scripting): Add entry about the new xmethods
feature.
doc/
* python.texi (Xmethods In Python, XMethod API)
(Writing an Xmethod): New nodes.
(Python API): New menu entries "Xmethods In Python",
"Xmethod API", "Writing an Xmethod".
* python/py-xmethods.c: New file.
* python/py-objfile.c (objfile_object): New field 'xmethods'.
(objfpy_dealloc): XDECREF on the new xmethods field.
(objfpy_new, objfile_to_objfile_object): Initialize xmethods
field.
(objfpy_get_xmethods): New function.
(objfile_getset): New entry 'xmethods'.
* python/py-progspace.c (pspace_object): New field 'xmethods'.
(pspy_dealloc): XDECREF on the new xmethods field.
(pspy_new, pspace_to_pspace_object): Initialize xmethods
field.
(pspy_get_xmethods): New function.
(pspace_getset): New entry 'xmethods'.
* python/python-internal.h: Add declarations for new functions.
* python/python.c (_initialize_python): Invoke
gdbpy_initialize_xmethods.
* python/lib/gdb/__init__.py (xmethods): New
attribute.
* python/lib/gdb/xmethod.py: New file.
* python/lib/gdb/command/xmethods.py: New file.
testuite/
* gdb.python/py-xmethods.cc: New testcase to test xmethods.
* gdb.python/py-xmethods.exp: New tests to test xmethods.
* gdb.python/py-xmethods.py: Python script supporting the
new testcase and tests.
* eval.c (evaluate_subexp_standard): Call the xmethod if the
best match method returned by find_overload_match is an xmethod.
* valarith.c (value_x_binop, value_x_unop): Call the xmethod if
the best matching operator returned by find_overload_match is an
xmethod.
* valops.c: #include "extension.h".
(find_method_list): Add "fn_list" and "xm_worker_vec" arguments.
Return void. The list of matching source methods is returned in
"fn_list" and a vector of matching debug method workers is
returned in "xm_worker_vec". Update all callers.
(value_find_oload_method_list): Likewise.
(find_oload_champ): Add "xm_worker_vec" parameter. If it is
non-NULL, then the index of the best matching method in this
vector is returned. Update all callers.
(find_overload_match): Include xmethods while performing overload
resolution.
* defs.h (enum lval_type): New enumerator "lval_xcallable".
* extension-priv.h (struct extension_language_ops): Add the
xmethod interface.
* extension.c (new_xmethod_worker, clone_xmethod_worker,
get_matching_xmethod_workers, get_xmethod_argtypes,
invoke_xmethod, free_xmethod_worker,
free_xmethod_worker_vec): New functions.
* extension.h: #include "common/vec.h".
New function declarations.
(struct xmethod_worker): New struct.
(VEC (xmethod_worker_ptr)): New vector type.
(xmethod_worker_ptr): New typedef.
(xmethod_worker_vec): Likewise.
* gdbtypes.c (gdbtypes_post_init): Initialize "xmethod" field of
builtin_type.
* gdbtypes.h (enum type_code): New enumerator TYPE_CODE_XMETHOD.
(struct builtin_type): New field "xmethod".
* valarith.c (value_ptradd): Assert that the value argument is not
lval_xcallable.
* valops.c (value_must_coerce_to_target): Return 0 for
lval_xcallable values.
* value.c (struct value): New field XM_WORKER in the field
LOCATION.
(value_address, value_raw_address): Return 0 for lval_xcallable
values.
(set_value_address): Assert that the value is not an
lval_xcallable.
(value_free): Free the associated xmethod worker when freeing
lval_xcallable values.
(set_value_component_location): Assert that the WHOLE value is not
lval_xcallable.
(value_of_xmethod, call_xmethod): New functions.
* value.h: Declare "struct xmethod_worker".
Declare new functions value_of_xmethod, call_xmethod.
with the following code...
12 Nested; -- break #1
13 return I; -- break #2
14 end;
(line 12 is a call to function Nested)
... we have noticed the following errorneous behavior on ppc-aix,
where, after having inserted a breakpoint at line 12 and line 13,
and continuing from the breakpoint at line 12, the program never
stops at line 13, running away until the program terminates:
% gdb -q func
(gdb) b func.adb:12
Breakpoint 1 at 0x10000a24: file func.adb, line 12.
(gdb) b func.adb:13
Breakpoint 2 at 0x10000a28: file func.adb, line 13.
(gdb) run
Starting program: /[...]/func
Breakpoint 1, func () at func.adb:12
12 Nested; -- break #1
(gdb) c
Continuing.
[Inferior 1 (process 4128872) exited with code 02]
When resuming from the first breakpoint, GDB first tries to step out
of that first breakpoint. We rely on software single-stepping on this
platform, and it just so happens that the address of the first
software single-step breakpoint is the same as the user's breakpoint
#2 (0x10000a28). So, with infrun and target traces turned on (but
uninteresting traces snip'ed off), the "continue" operation looks like
this:
(gdb) c
### First, we insert the user breakpoints (the second one is an internal
### breakpoint on __pthread_init). The first user breakpoint is not
### inserted as we need to step out of it first.
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000d03f3800, xxx) = 0
### Then we proceed with the step-out-of-breakpoint...
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 15335610] at 0x10000a24
### That's when we insert the SSS breakpoints...
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000100009ac, xxx) = 0
### ... then let the inferior resume...
target_resume (15335610, continue, 0)
infrun: wait_for_inferior ()
target_wait (-1, status, options={}) = 15335610, status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: target_wait (-1, status) =
infrun: 15335610 [process 15335610],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x100009ac
### At this point, we stopped at the second SSS breakpoint...
target_stopped_by_watchpoint () = 0
### We remove the SSS breakpoints...
target_remove_breakpoint (0x0000000010000a28, xxx) = 0
target_remove_breakpoint (0x00000000100009ac, xxx) = 0
target_stopped_by_watchpoint () = 0
### We find that we're not done, so we resume....
infrun: no stepping, continue
### And thus insert the user breakpoints again, except we're not
### inserting the second breakpoint?!?
target_insert_breakpoint (0x0000000010000a24, xxx) = 0
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 15335610] at 0x100009ac
target_resume (-1, continue, 0)
infrun: prepare_to_wait
target_wait (-1, status, options={}) = 15335610, status->kind = exited, status = 2
What happens is that the removal of the software single-step
breakpoints effectively removed the breakpoint instruction from
inferior memory. But because such breakpoints are inserted directly
as raw breakpoints rather than through the normal chain of
breakpoints, we fail to notice that one of the user breakpoints points
to the same address and that this user breakpoint is therefore
effectively un-inserted. When resuming after the single-step, GDB
thinks that the user breakpoint is still inserted and therefore does
not need to insert it again.
This patch teaches the insert and remove routines of both regular and
raw breakpoints to be aware of each other. Special care needs to be
applied in case the target supports evaluation of breakpoint
conditions or commands.
gdb/ChangeLog:
PR breakpoints/17000
* breakpoint.c (find_non_raw_software_breakpoint_inserted_here):
New function, extracted from software_breakpoint_inserted_here_p.
(software_breakpoint_inserted_here_p): Replace factored out code
by call to find_non_raw_software_breakpoint_inserted_here.
(bp_target_info_copy_insertion_state): New function.
(bkpt_insert_location): Handle the case of a single-step
breakpoint already inserted at the same address.
(bkpt_remove_location): Handle the case of a single-step
breakpoint still inserted at the same address.
(deprecated_insert_raw_breakpoint): Handle the case of non-raw
breakpoint already inserted at the same address.
(deprecated_remove_raw_breakpoint): Handle the case of a
non-raw breakpoint still inserted at the same address.
(find_single_step_breakpoint): New function, extracted from
single_step_breakpoint_inserted_here_p.
(find_single_step_breakpoint): New function,
factored out from single_step_breakpoint_inserted_here_p.
(single_step_breakpoint_inserted_here_p): Reimplement.
gdb/testsuite/ChangeLog:
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp.exp: Remove kfail.
* gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail.
Tested on ppc-aix with AdaCore's testsuite. Tested on x86_64-linux,
(native and gdbserver) with the official testsuite. Also tested on
x86_64-linux through Pedro's branch enabling software single-stepping
on that platform (native and gdbserver).
out that the section is supposed to be page-aligned, but the newly merged
section was not being padded out to a page boundary. This meant that when
the executable was stripped a badly sized .rsrc section was written out.
PR ld/16807
* peXXigen.c (rsrc_process_section): Page align the new contents
befgore writing out.
The check for the source (or "from") directory snippet in listing
matching path substitution rules currently will not match anything
other than a direct match of the "from" field in a substitution rule,
resulting in the incorrect behavior below:
...
(gdb) set substitute-path /a/path /another/path
(gdb) show substitute-path
List of all source path substitution rules:
`/a/path' -> `/another/path'.
(gdb) show substitute-path /a/path/to/a/file.ext
Source path substitution rule matching `/a/path/to/a/file.ext':
(gdb) show substitute-path /a/path
Source path substitution rule matching `/a/path':
`/a/path' -> `/another/path'.
...
This change effects the following behavior by (sanely) checking
with the length of the "from" portion of a rule and ensuring that
the next character of the path considered for substitution is a path
delimiter (or NULL). With this change, the following behavior is
garnered:
...
(gdb) set substitute-path /a/path /another/path
(gdb) show substitute-path
List of all source path substitution rules:
`/a/path' -> `/another/path'.
(gdb) show substitute-path /a/path/to/a/file.ext
Source path substitution rule matching `/a/path/to/a/file.ext':
`/a/path' -> `/another/path'.
(gdb) show substitute-path /a/pathological/case/that/should/fail.err
Source path substitution rule matching `/a/pathological/case/that/should/fail.err':
(gdb)
Also included is a couple of tests added to subst.exp to verify
this behavior in the test suite.
gdb/ChangeLog:
* source.c (show_substitute_path_command): Fix display of matching
substitution rules.
gdb/testsuite/ChangeLog:
* gdb.ada/subst.exp: Add tests to verify partial path matching
output.
This was tested on x86_64 Linux.
gdb/testsuite/
2014-06-03 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Skip if testing with a remote
target that doesn't use software single-stepping.
gdb_demangle. This change was included in an RFC from last
March [1] but omitted from the eventual commit.
[1] https://sourceware.org/ml/gdb-patches/2013-03/msg00235.html
2014-06-03 Gary Benson <gbenson@redhat.com>
* gnu-v2-abi.c (gnuv2_value_rtti_type): Use gdb_demangle.
GDB gets confused when removing a software single-step breakpoint that
is at the same address as another breakpoint. Add another kfailed
test.
gdb/testsuite/
2014-06-03 Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp-2.c: New file.
* gdb.base/sss-bp-on-user-bp-2.exp: New file.
