Fix a typo in the expedited registers for s390-te-linux64.
gdb/ChangeLog:
* features/Makefile (s390-te-linux64-expedite): Replace
non-existant r14 and r15 by r14l and r15l, respectively.
* regformats/s390-te-linux64.dat: Regenerate.
The message displayed when using help() changed a bit with time, so this
adjusts the test accordingly.
gdb/testsuite/ChangeLog:
* gdb.python/python.exp: Change expected reply to help().
Remove native-only core file handling on GNU Hurd. Instead, enable the
x86 target generic core regset logic on the Hurd by providing an
appropriate register offset map.
Thanks to Samuel Thibault for testing!
gdb/
* config/i386/i386gnu.mh (NATDEPFILES): Remove core-regset.o.
* i386gnu-nat.c: Do not include <sys/procfs.h> or "gregset.h".
(CREG_OFFSET, creg_offset, CREG_ADDR): Remove.
(supply_gregset, supply_fpregset): Remove.
* i386gnu-tdep.c (i386gnu_gregset_reg_offset): New variable.
(i386gnu_init_abi): Set tdep->gregset_reg_offset, gregset_num_regs,
and sizeof_gregset.
When I skim configure.ac and Makefile.in in gdb/testsuite, I happen to
see that directory gdb.gdbtk is added to subdirs, however it doesn't
exist. gdb/testsuite/gdb.gdbtk was removed by the patch below,
[rfa] git repo fixup: delete gdb/testsuite/gdb.gdbtk
http://thread.gmane.org/gmane.comp.gdb.patches/61489
and we should cleanup configure.ac accordingly.
gdb/testsuite:
2014-12-01 Yao Qi <yao@codesourcery.com>
* configure.ac: Remove AC_ARG_ENABLE for gdbtk. Don't invoke
AC_CONFIG_SUBDIRS(gdb.gdbtk).
* configure: Re-generated.
There is already "add-auto-load-safe-path" which works
like "set auto-load safe-path" but in append mode.
There was missing an append equivalent for "set auto-load scripts-directory".
ABRT has directory /var/cache/abrt-di/ as an alternative one
to /usr/lib/debug/ . Therefore ABRT needs to use -iex parameters to add this
/var/cache/abrt-di/ directory as a first-class debuginfo directory.
Using absolute "set auto-load scripts-directory" would hard-code the path
possibly overriding local system directory additions; besides it would not be
nice anyway.
gdb/ChangeLog
2014-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Add add-auto-load-scripts-directory.
* NEWS (Changes since GDB 7.8): Add add-auto-load-scripts-directory.
* auto-load.c (add_auto_load_dir): New function.
(_initialize_auto_load): Install it.
gdb/doc/ChangeLog
2014-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Add add-auto-load-scripts-directory.
* gdb.texinfo (Auto-loading): Add add-auto-load-scripts-directory link.
(objfile-gdbdotext file): Add add-auto-load-scripts-directory.
I noticed in frame_id_eq() we were checking for the "l" frame_id being
invalid twice instead of checking both "l" and "r", so this patch
corrects it.
gdb/ChangeLog:
* frame.c (frame_id_eq): Fix the check for FID_STACK_INVALID.
This fixes a regression introduced by 6c659fc2c7.
gdb/ChangeLog:
* eval.c (evaluate_subexp): Check that thread stack temporaries
are not already enabled before enabling them.
I find local variables framereg and framesize is only used when cache
isn't NULL. This patch to move the code into "if (cache)" block.
gdb:
2014-11-29 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (arm_analyze_prologue): Move local variables
'framereg' and 'framesize' to inner block. Move code to
inner block too.
gdb/ChangeLog:
* eval.c: Include gdbthread.h.
(evaluate_subexp): Enable thread stack temporaries before
evaluating a complete expression and clean them up after the
evaluation is complete.
* gdbthread.h: Include common/vec.h.
(value_ptr): New typedef.
(VEC (value_ptr)): New vector type.
(value_vec): New typedef.
(struct thread_info): Add new fields stack_temporaries_enabled
and stack_temporaries.
(enable_thread_stack_temporaries)
(thread_stack_temporaries_enabled_p, push_thread_stack_temporary)
(get_last_thread_stack_temporary)
(value_in_thread_stack_temporaries): Declare.
* gdbtypes.c (class_or_union_p): New function.
* gdbtypes.h (class_or_union_p): Declare.
* infcall.c (call_function_by_hand): Store return values of class
type as temporaries on stack.
* thread.c (enable_thread_stack_temporaries): New function.
(thread_stack_temporaries_enabled_p, push_thread_stack_temporary)
(get_last_thread_stack_temporary): Likewise.
(value_in_thread_stack_temporaries): Likewise.
* value.c (value_force_lval): New function.
* value.h (value_force_lval): Declare.
gdb/testsuite/ChangeLog:
* gdb.cp/chained-calls.cc: New file.
* gdb.cp/chained-calls.exp: New file.
* gdb.cp/smartp.exp: Remove KFAIL for "p c2->inta".
Python 3's print requires to use parentheses, so this patch adds them
where they were missing.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range.exp: Add parentheses to calls to print.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.gdb/python-interrupts.exp: Same.
* gdb.gdb/python-selftest.exp: Same.
* gdb.python/py-linetable.exp: Same.
* gdb.python/py-type.exp: Same.
* gdb.python/py-value-cc.exp: Same.
* gdb.python/py-value.exp: Same.
Dwarf register numbers are defined in "System V Application Binary
Interface AMD64 Architecture Processor Supplement Draft Version 0.99.6"
The amd64_dwarf_regmap array is missing the 8 MMX registers in Figure
3.36: DWARF Register Number Mapping page 57. This leads to a wrong
value for the registers past this point.
gdb/ChangeLog:
Pushed by Joel Brobecker <brobecker@adacore.com>.
* amd64-tdep.c (amd64_dwarf_regmap array): Add missing MMX
registers.
Tested on x86_64-linux.
Since Andreas Arnez' recent patch series, all Linux targets install
gdbarch_iterate_over_regset_sections routines. This means that on
Linux native targets, old-style core sniffers are never used.
Most Linux targets haven't been using such sniffers for a long time
anyway, but a couple remain: ia64 and sparc use core-regset.o, and
m68k installs its own core_fns. All this is now dead code, which
this commit removes.
gdb/
2014-11-28 Ulrich Weigand <uweigand@de.ibm.com>
* config/ia64/linux.mh (NATDEPFILES): Remove core-regset.o.
* config/sparc/linux.mh (NATDEPFILES): Likewise.
* config/sparc/linux64.mh (NATDEPFILES): Likewise.
* m68klinux-nat.c (fetch_core_registers): Remove.
(linux_elf_core_fns): Remove.
(_initialize_m68k_linux_nat): Do not call deprecated_add_core_fns.
Rework the comment to explain why we're still relying on GetFullPathName
even though gnulib ensures that canonicalize_file_name is now available
on all platforms, including Windows.
gdb/ChangeLog:
* utils.c (gdb_realpath): Rework comment about handling on
Windows.
Since lstat gnulib module is imported, we can use it unconditionally.
lstat usage was introduced by this patch
https://sourceware.org/ml/gdb-patches/2012-01/msg00390.html
during the review, it was suggested to import gnulib lstat module, but
we didn't do that.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac (AC_CHECK_FUNCS): Remove lstat.
* config.in, configure: Regenerate.
* symfile.c (find_separate_debug_file_by_debuglink): Remove
code checking HAVE_LSTAT is defined.
Since readlink module is imported, we can use it unconditionally.
This patch is to remove configure checks and HAVE_READLINK checks in
code. It was mentioned in the patch below
[RFA/commit] gdbserver: return ENOSYS if readlink not supported.
https://sourceware.org/ml/gdb-patches/2012-02/msg00148.html
to use readlink in gdbserver, but we chose something simple at that
moment.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac (AC_CHECK_FUNCS): Remove readlink.
* config.in, configure: Re-generate.
* inf-child.c (inf_child_fileio_readlink): Don't check
HAVE_READLINK is defined.
gdb/gdbserver:
2014-11-28 Yao Qi <yao@codesourcery.com>
* configure.ac(AC_CHECK_FUNCS): Remove readlink.
* config.in, configure: Re-generate.
* hostio.c (handle_unlink): Remove code checking HAVE_READLINK
is defined.
This patch is to import readlink gnulib module. stat module is imported
too, but it isn't used by gdb.
gdb:
2014-11-28 Yao Qi <yao@codesourcery.com>
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add readlink.
* gnulib/aclocal.m4: Re-generated.
* gnulib/config.in: Likewise.
* gnulib/configure: Likewise.
* gnulib/import/Makefile.am: Likewise.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
* gnulib/import/m4/gnulib-comp.m4: Likewise.
* gnulib/import/dosname.h: New file
* gnulib/import/m4/largefile.m4: New file.
* gnulib/import/m4/readlink.m4: New file.
* gnulib/import/m4/stat.m4: New file.
* gnulib/import/readlink.c: New file.
* gnulib/import/stat.c: New file.
We enable systemtap probe in glibc recently, and see the following gdb fail,
(gdb) set solib-absolute-prefix /.
...
Stopped due to shared library event:^M
Inferior loaded /./foo/bar/gdb.base/break-probes-solib.so
...
(gdb) FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
$binfile_lib is /foo/bar/gdb.base/break-probes-solib.so, but the
sysroot is prefixed in solib.c:solib_find, as comments described:
Global variable GDB_SYSROOT is used as a prefix directory
to search for shared libraries if they have an absolute path.
so the output becomes "/./foo/bar/gdb.base/break-probes-solib.so", which
is still correct. However, the test repeatedly continue the program
and tries to match $binfile_lib, finally, the program exits and the
test fails.
This patch is to adjust the pattern to match $sysroot$binfile_lib
instead of $binfile_lib.
gdb/testsuite:
2014-11-28 Yao Qi <yao@codesourcery.com>
* gdb.base/break-probes.exp: Match library name prefixed with
sysroot.
The following test is found in python/py-linetable.exp:
gdb_test "python print sorted(fset)" \
"\[20L, 21L, 22L, 24L, 25L, 28L, 29L, 30L, 32L, 33L, 37L, 39L, 40L, 42L, 44L, 45L, 46L\].*" \
"Test frozen set contains line numbers"
I noticed that it passed when using Python 3, even though it should fail
because of the missing parentheses for the call print.
There needs to be more escaping of the square brackets. Currently, it is
interpreted as "any one character from this big list of characters,
followed by .*". When adding the required amount of backslashes, the
test starts failing as it should.
Moreover, both in Python 2.7 and Python 3.3 the numbers don't have the L
suffix, so now the test fails because of that. Anybody knows why they
were there in the first place? I just tested with Python 2.4 and there
are no Ls.
gdb/testsuite/ChangeLog:
* gdb.python/py-linetable.exp: Escape properly sorted(fset)
test expected output. Add parentheses for the call to print.
Remove L suffix from integers.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
2014-11-25 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_analyze_prologue): Replace restriction
that there can be only one stack adjustment in the prologue
with tests to detect specific disallowed stack adjustments.
instruction matching.
2014-11-25 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (nios2_fetch_insn): Move up in file. Disassemble
the instruction as well as reading it from memory.
(nios2_match_add): New.
(nios2_match_sub): New.
(nios2_match_addi): New.
(nios2_match_orhi): New.
(nios2_match_stw): New.
(nios2_match_ldw): New.
(nios2_match_rdctl): New.
(enum branch_condition): New.
(nios2_match_branch): New.
(nios2_match_jmpi): New.
(nios2_match_calli): New.
(nios2_match_jmpr): New.
(nios2_match_callr): New.
(nios2_match_break): New.
(nios2_match_trap): New.
(nios2_in_epilogue_p): Rewrite to use new functions.
(nios2_analyze_prologue): Likewise.
(nios2_skip_prologue): Delete unused local limit_pc.
(nios2_breakpoint_from_pc): Make R1-specific encodings explicit.
(nios2_get_next_pc): Rewrite to use new functions.
2014-11-24 Samuel Thibault <samuel.thibault@ens-lyon.org>
* gdb/gnu-nat.c (inf_validate_procinfo): Multiply the number of
elements pi_len by the size of the elements before calling
vm_deallocate.
(inf_validate_task_sc): Likewise, and properly deallocate the
noise array.
gdb/ChangeLog:
* gdbtypes.c (print_args): Renamed from print_arg_types. Print arg
number and name if present. All callers updated.
(dump_fn_fieldlists): Fix indentation of args.
A recent change...
commit 1a853c5224
Date: Wed Nov 12 10:10:49 2014 +0000
Subject: make "permanent breakpoints" per location and disableable
... broke function calls on sparc-elf when running over QEMU. Any
function call should demonstrate the problem.
For instance, seen from the debugger:
(gdb) call pn(1234)
[Inferior 1 (Remote target) exited normally]
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
And seen from QEMU:
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
[register dump removed]
What happens in this case is that GDB sets the inferior function call
by not only creating the dummy frame, but also writing a breakpoint
instruction at the return address for our function call. See infcall.c:
/* Write a legitimate instruction at the point where the infcall
breakpoint is going to be inserted. While this instruction
is never going to be executed, a user investigating the
memory from GDB would see this instruction instead of random
uninitialized bytes. We chose the breakpoint instruction
as it may look as the most logical one to the user and also
valgrind 3.7.0 needs it for proper vgdb inferior calls.
If software breakpoints are unsupported for this target we
leave the user visible memory content uninitialized. */
bp_addr_as_address = bp_addr;
bp_bytes = gdbarch_breakpoint_from_pc (gdbarch, &bp_addr_as_address,
&bp_size);
if (bp_bytes != NULL)
write_memory (bp_addr_as_address, bp_bytes, bp_size);
This instruction triggers a change introduced by the commit above,
where we consider bp locations as being permanent breakpoints
if there is already a breakpoint instruction at that address:
+ if (bp_loc_is_permanent (loc))
+ {
+ loc->inserted = 1;
+ loc->permanent = 1;
+ }
As a result, when resuming the program's execution for the inferior
function call, GDB decides that it does not need to insert a breakpoint
at this address, expecting the target to just report a SIGTRAP when
trying to execute that instruction.
But unfortunately for us, at least some versions of QEMU for SPARC
just terminate the execution entirely instead of reporting a breakpoint,
thus producing the behavior reported here.
Although it appears like QEMU might be misbehaving and should therefore
be fixed (to be verified) from the user's point of view, the recent
change does introduce a regression. So this patch tries to mitigate
a bit the damage by handling such infcall breakpoints as special and
making sure that they are never considered permanent, thus restoring
the previous behavior specifically for those breakpoints.
The option of not writing the breakpoint instructions in the first
place was considered, and would probably work also. But the comment
associated to it seems to indicate that there is still reason to
keep it.
gdb/ChangeLog:
* breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
to a bp_call_dummy breakpoint type.
Tested on x86_64-linux. Also testing on sparc-elf/QEMU using
AdaCore's testsuite.
SA_RESTART allows system calls to be restarted across a signal handler.
By specifying this flag we fix the issue where if the user is being
prompted to answer yes or no, and the terminal gets resized in the
meantime, the prompt will think that the user sent an EOF and so it will
take the default action for that prompt (in the case of the quit prompt,
it will quit GDB).
gdb/ChangeLog:
* tui/tui-win.c (tui_initialize_win): Specify SA_RESTART when
registering the signal handler.
This patch fixes the annoying bug where key sequences such as Alt_F or
Alt_B (go forward or backwards by a word) do not behave promptly in TUI.
You have to press a third key in order for the key sequence to register.
This is mostly ncurses' fault. Calling wgetch() normally causes ncurses
to read only a single key from stdin. However if the key read is the
start-sequence key (^[ a.k.a. ESC) then wgetch() reads TWO keys from
stdin, storing the 2nd key into an internal FIFO buffer and returning
the start-sequence key. The extraneous read of the 2nd key makes us
miss its corresponding stdin event, so the event loop blocks until a
third key is pressed. This explains why such key sequences do not
behave promptly in TUI.
To fix this issue, we must somehow compensate for the missed stdin event
corresponding to the 2nd byte of a key sequence. This patch achieves
this by hacking up the stdin event handler to conditionally execute the
readline callback multiple times in a row. This is done via a new
global variable, call_stdin_event_handler_again_p, which is set from
tui_getc() when we receive a start-sequence key and notice extra pending
input in the ncurses buffer.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* event-top.h (call_stdin_event_handler_again_p): Declare.
* event-top.c (call_stdin_event_handler_again_p): Define.
(stdin_event_handler): Use it.
* tui/tui-io.c (tui_getc): Prepare to call the stdin event
handler again if there is pending input following a
start sequence.
This way the user can know the index of the latest checkpoint without
having to run "info checkpoints" afterwards.
gdb/ChangeLog:
* linux-fork.c (checkpoint_command): Print index of new
checkpoint in response message.
In read_string, we have this line
chunksize = (len == -1 ? min (8, fetchlimit) : fetchlimit);
but chunksize is only used in the block that lne == -1, so IWBN to
move chunksize to the block in which it is used, and simplify the
condition setting chunksize. This patch also moves 'found_nul' to
inner block. This patch also splits a paragraph of comment into two,
and move them to different condition blocks (len > 0 and len == -1)
respectively.
gdb:
2014-11-23 Yao Qi <yao@codesourcery.com>
* valprint.c (read_string): Move local variables 'found_nul',
'chunksize' and 'limit' to inner scope. Update comments.
MACRO_AT_func can be used in gdb.trace/entry-values.exp to correctly
get function's address in generated debug info. As a result, the test
is more friendly to clang. Currently, there are some fails in
entry-values.exp when the test is compiled by clang. With this patch
applied, all fails go away.
gdb/testsuite:
2014-11-22 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.c: Remove asms.
(foo): Add foo_label.
(bar): Add bar_label.
* gdb.trace/entry-values.exp: Remove code computing foo's
length and bar's length.
(Dwarf::assemble): Invoke function_range for bar and use
MACRO_AT_func for foo.
This patch fixes two fails in dw2-compdir-oldgcc.exp I've seen on arm
target thumb mode.
FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42
FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc43
When fill in DW_AT_low_pc, the label should be used rather than the
function, otherwise, the LSB bit of the address in DW_AT_low_pc is
set and the debug info is wrong. This patch is to add two labels for
functions gcc42 and gcc43 respectively, and use them. These two
fails are fixed.
gdb/testsuite:
2014-11-22 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-compdir-oldgcc.S: Define label .Lgcc42_procstart
and .Lgcc43_procstart. Use .Lgcc42_procstart instead of gcc42.
Use .Lgcc43_procstart instead of gcc43.
errno.h is included in common/common-defs.h, and gnulib errno module
was imported to gdb. This patch is to import it explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
errno.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
As gnulib modules wchar and wctype is imported, we can include wchar.h
and wctype.h unconditionally. This patch is also to remove HAVE_WCHAR_H
check.
gdb:
2014-11-21 Yao Qi <yao@codesourcery.com>
* gdb_wchar.h: Include wchar.h and wctype.h.
[HAVE_ICONV && HAVE_BTOWC]: Don't check HAVE_WCHAR_T and don't
include wchar.h and wctype.h.
Don't check HAVE_WCHAR_H.
gnulib module wchar and wctype-h was imported as a dependency, but
they are used by gdb_wchar.h too. This patch is to import them
explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add wchar
and wctype-h.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
memchr has been used in gdb source and gnulib memchr module was
imported as a dependency. This patch is to import it explicitly.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
memchr.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise.
* gnulib/import/m4/gnulib-cache.m4: Likewise.
Since gnulib alloca module was imported, we can include alloca.h in
both gdb and gdbserver unconditionally, so this patch adds inclusion
of alloca.h in common-defs.h. This patch also removes AC_FUNC_ALLOCA
in configure.ac because we don't need to check alloca any more.
This patch below is removed in fact.
[RFA/commit] include alloca.h if available.
https://www.sourceware.org/ml/gdb-patches/2010-08/msg00566.html
Since alloca.h is from gnulib now, we don't have to check malloc.h in
configure and include malloc.h in code. This patch also remove them
too.
gdb:
2014-11-21 Yao Qi <yao@codesourcery.com>
* common/common-defs.h: Include alloca.h
* configure.ac: Don't invoke AC_FUNC_ALLOCA.
* configure: Re-generated.
* defs.h: Remove code handling alloca.
* utils.c (gdb_realpath): Don't check HAVE_ALLOCA is defined
or not.
gdb/gdbserver:
2014-11-21 Yao Qi <yao@codesourcery.com>
* configure.ac: Don't invoke AC_FUNC_ALLOCA.
(AC_CHECK_HEADERS): Remove malloc.h.
* configure: Re-generated.
* config.in: Re-generated.
* server.h: Don't include alloca.h and malloc.h.
* gdbreplay.c: Don't check HAVE_ALLOCA_H is defined.
Don't include malloc.h.
gnulib's alloca module was imported to gdb, and alloca is used. This
patch is to explicitly import it.
gdb:
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULE): Add
alloca.
* gnulib/import/Makefile.am: Re-generated.
* gnulib/import/Makefile.in: Likewise..
* gnulib/import/m4/gnulib-cache.m4: Likewise.
Since we'll add more modules in this list, better to keep them in
alphabetical order.
gdb:
* gnulib/update-gnulib.sh: Make IMPORTED_GNULIB_MODULES in
alphabetical order.
Consider the following variable declaration:
type Array_Type is array (Integer range <>) of Integer;
Var: Array_Type (0 .. -1);
"ptype var" prints the wrong upper bound for that array:
(gdb) ptype var
type = array (0 .. 4294967295) of integer
The debugging info for the type of variable "Var" is as follow:
<2><cf>: Abbrev Number: 13 (DW_TAG_structure_type)
<d0> DW_AT_name : foo__var___PAD
<3><db>: Abbrev Number: 14 (DW_TAG_member)
<dc> DW_AT_name : F
<e0> DW_AT_type : <0xa5>
This is just an artifact from code generation, which is just
a wrapper that we should ignore. The real type is the type of
field "F" in that PAD type, which is described as:
<2><a5>: Abbrev Number: 10 (DW_TAG_array_type)
<a6> DW_AT_name : foo__TvarS
<3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type)
<b7> DW_AT_type : <0xc1>
<bb> DW_AT_lower_bound : 0
<bc> DW_AT_upper_bound : 0xffffffff
Trouble occurs because DW_AT_upper_bound is encoded using
a DW_FORM_data4, which is ambiguous regarding signedness.
In that case, dwarf2read.c::dwarf2_get_attr_constant_value
reads the value as unsigned, which is not what we want
in this case.
As it happens, we already have code dealing with this situation
in dwarf2read.c::read_subrange_type which checks whether
the subrange's type is signed or not, and if it is, fixes
the bound's value by sign-extending it:
if (high.kind == PROP_CONST
&& !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask))
high.data.const_val |= negative_mask;
Unfortunately, what happens in our case is that the base type
of the array's subrange type is marked as being unsigned, and
so we never get to apply the sign extension. Following the DWARF
trail, the range's base type is described as another subrange type...
<2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type)
<c7> DW_AT_name : foo__TTvarSP1___XDLU_0__1m
<cb> DW_AT_type : <0x2d>
... whose base type is, (finally), a basic type (signed):
<1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
<2e> DW_AT_byte_size : 4
<2f> DW_AT_encoding : 5 (signed)
<30> DW_AT_name : integer
The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m
(the base type of the array's range type) is an unsigned type
is found in gdbtypes.c::create_range_type. We consider that
a range type is unsigned iff its lower bound is >= 0:
if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0)
TYPE_UNSIGNED (result_type) = 1;
That is normally sufficient, as one would expect the upper bound to
always be greater or equal to the lower bound. But Ada actually
allows the declaration of empty range types where the upper bound
is less than the lower bound. In this case, the upper bound is
negative, so we should not be marking the type as unsigned.
This patch fixes the issue by simply checking the upper bound as well
as the lower bound, and clears the range type's unsigned flag when
it is found to be constant and negative.
gdb/ChangeLog:
* gdbtypes.c (create_range_type): Unset RESULT_TYPE's
flag_unsigned if HIGH_BOUND is constant and negative.
gdb/testsuite/ChangeLog:
* gdb.ada/n_arr_bound: New testcase.
Tested on x86_64-linux.
In the previous commit, I forgot to adjust the prototypes of the
functions inside gdb/xml-syscall.c for the case when GDB is compiled
without XML support.
gdb/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* xml-syscall.c (set_xml_syscall_file_name): Remove "const"
modifier from "struct gdbarch" when compiling without Expat (XML)
support.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
This patch intends to partially fix PR breakpoints/10737, which is
about making the syscall information (for the "catch syscall" command)
be per-arch, instead of global. This is not a full fix because of the
other issues pointed by Pedro here:
<https://sourceware.org/bugzilla/show_bug.cgi?id=10737#c5>
However, I consider it a good step towards the real fix. It will also
help me fix <https://sourceware.org/bugzilla/show_bug.cgi?id=17402>.
What this patch does, basically, is move the "syscalls_info"
struct to gdbarch. Currently, the syscall information is stored in a
global variable inside gdb/xml-syscall.c, which means that there is no
easy way to correlate this info with the current target or
architecture being used, for example. This causes strange behaviors,
because the syscall info is not re-read when the arch changes. For
example, if you put a syscall catchpoint in syscall 5 on i386 (syscall
open), and then load a x86_64 program on GDB and put the same syscall
5 there (fstat on x86_64), you will still see that GDB tells you that
it is catching "open", even though it is not. With this patch, GDB
correctly says that it will be catching fstat syscalls.
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'open' [5])
But with the patch:
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'fstat' [5])
As I said, there are still some problems on the "catch syscall"
mechanism, because (for example) the user should be able to "catch
syscall open" on i386, and then expect "open" to be caught also on
x86_64. Currently, it doesn't work. I intend to work on this later.
gdb/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* breakpoint.c (print_it_catch_syscall): Adjust call to
get_syscall_by_number to provide gdbarch.
(print_one_catch_syscall): Likewise.
(print_mention_catch_syscall): Likewise.
(print_recreate_catch_syscall): Likewise.
(catch_syscall_split_args): Adjust calls to get_syscall_by_number
and get_syscall_by_name to provide gdbarch.
(catch_syscall_completer): Adjust call to get_syscall_names to
provide gdbarch.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* gdbarch.sh: Forward declare "struct syscalls_info".
(xml_syscall_file): New variable.
(syscalls_info): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_gdbarch_init): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* xml-syscall.c: Include gdbarch.h.
(set_xml_syscall_file_name): Accept gdbarch parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
(my_gdb_datadir): Delete global variable.
(struct syscalls_info) <my_gdb_datadir>: New variable.
(struct syscalls_info) <sysinfo>: Rename variable to
"syscalls_info".
(sysinfo): Delete global variable.
(have_initialized_sysinfo): Likewise.
(xml_syscall_file): Likewise.
(sysinfo_free_syscalls_desc): Rename to...
(syscalls_info_free_syscalls_desc): ... this.
(free_syscalls_info): Rename "sysinfo" to "syscalls_info". Adjust
code to the new layout of "struct syscalls_info".
(make_cleanup_free_syscalls_info): Rename parameter "sysinfo" to
"syscalls_info".
(syscall_create_syscall_desc): Likewise.
(syscall_start_syscall): Likewise.
(syscall_parse_xml): Likewise.
(xml_init_syscalls_info): Likewise. Drop "const" from return value.
(init_sysinfo): Rename to...
(init_syscalls_info): ...this. Add gdbarch as a parameter.
Adjust function to deal with gdbarch.
(xml_get_syscall_number): Delete parameter sysinfo. Accept
gdbarch as a parameter. Adjust code.
(xml_get_syscall_name): Likewise.
(xml_list_of_syscalls): Likewise.
(set_xml_syscall_file_name): Accept gdbarch as parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
* xml-syscall.h (set_xml_syscall_file_name): Likewise.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
gdb/testsuite/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* gdb.base/catch-syscall.exp (do_syscall_tests): Call
test_catch_syscall_multi_arch.
(test_catch_syscall_multi_arch): New function.
Currently "symtabs" in gdb are stored as a single linked list of
struct symtab that contains both symbol symtabs (the blockvectors)
and file symtabs (the linetables).
This has led to confusion, bugs, and performance issues.
This patch is conceptually very simple: split struct symtab into
two pieces: one part containing things common across the entire
compilation unit, and one part containing things specific to each
source file.
Example.
For the case of a program built out of these files:
foo.c
foo1.h
foo2.h
bar.c
foo1.h
bar.h
Today we have a single list of struct symtabs:
objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL
where "->" means the "next" pointer in struct symtab.
With this patch, that turns into:
objfile -> foo.c(cu) -> bar.c(cu) -> NULL
| |
v v
foo.c bar.c
| |
v v
foo1.h foo1.h
| |
v v
foo2.h bar.h
| |
v v
NULL NULL
where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects,
and the files foo.c, etc. are struct symtab objects.
So now, for example, when we want to iterate over all blockvectors
we can now just iterate over the compunit_symtab list.
Plus a lot of the data that was either unused or replicated for each
symtab in a compilation unit now lives in struct compunit_symtab.
E.g., the objfile pointer, the producer string, etc.
I thought of moving "language" out of struct symtab but there is
logic to try to compute the language based on previously seen files,
and I think that's best left as is for now.
With my standard monster benchmark with -readnow (which I can't actually
do, but based on my calculations), whereas today the list requires
77MB to store all the struct symtabs, it now only requires 37MB.
A modest space savings given the gigabytes needed for all the debug info,
etc. Still, it's nice. Plus, whereas today we create a copy of dirname
for each source file symtab in a compilation unit, we now only create one
for the compunit.
So this patch is basically just a data structure reorg,
I don't expect significant performance improvements from it.
Notes:
1) A followup patch can do a similar split for struct partial_symtab.
I have left that until after I get the changes I want in to
better utilize .gdb_index (it may affect how we do partial syms).
2) Another followup patch *could* rename struct symtab.
The term "symtab" is ambiguous and has been a source of confusion.
In this patch I'm leaving it alone, calling it the "historical" name
of "filetabs", which is what they are now: just the file-name + line-table.
gdb/ChangeLog:
Split struct symtab into two: struct symtab and compunit_symtab.
* amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit.
* block.c (blockvector_for_pc_sect): Change "struct symtab *" argument
to "struct compunit_symtab *". All callers updated.
(set_block_compunit_symtab): Renamed from set_block_symtab. Change
"struct symtab *" argument to "struct compunit_symtab *".
All callers updated.
(get_block_compunit_symtab): Renamed from get_block_symtab. Change
result to "struct compunit_symtab *". All callers updated.
(find_iterator_compunit_symtab): Renamed from find_iterator_symtab.
Change result to "struct compunit_symtab *". All callers updated.
* block.h (struct global_block) <compunit_symtab>: Renamed from symtab.
hange type to "struct compunit_symtab *". All uses updated.
(struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab".
Change type to "struct compunit_symtab *". All uses updated.
* buildsym.c (struct buildsym_compunit): New struct.
(subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete.
(buildsym_compunit): New static global.
(finish_block_internal): Update to fetch objfile from
buildsym_compunit.
(make_blockvector): Delete objfile argument.
(start_subfile): Rewrite to use buildsym_compunit. Don't initialize
debugformat, producer.
(start_buildsym_compunit): New function.
(free_buildsym_compunit): Renamed from free_subfiles_list.
All callers updated.
(patch_subfile_names): Rewrite to use buildsym_compunit.
(get_compunit_symtab): New function.
(get_macro_table): Delete argument comp_dir. All callers updated.
(start_symtab): Change result to "struct compunit_symtab *".
All callers updated. Create the subfile of the main source file.
(watch_main_source_file_lossage): Rewrite to use buildsym_compunit.
(reset_symtab_globals): Update.
(end_symtab_get_static_block): Update to use buildsym_compunit.
(end_symtab_without_blockvector): Rewrite.
(end_symtab_with_blockvector): Change result to
"struct compunit_symtab *". All callers updated.
Update to use buildsym_compunit. Don't set symtab->dirname,
instead set it in the compunit.
Explicitly make sure main symtab is first in its list.
Set debugformat, producer, blockvector, block_line_section, and
macrotable in the compunit.
(end_symtab_from_static_block): Change result to
"struct compunit_symtab *". All callers updated.
(end_symtab, end_expandable_symtab): Ditto.
(set_missing_symtab): Change symtab argument to
"struct compunit_symtab *". All callers updated.
(augment_type_symtab): Ditto.
(record_debugformat): Update to use buildsym_compunit.
(record_producer): Update to use buildsym_compunit.
* buildsym.h (struct subfile) <dirname>: Delete.
<producer, debugformat>: Delete.
<buildsym_compunit>: New member.
(get_compunit_symtab): Declare.
* dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed
from primary_symtab. Change type to "struct compunit_symtab *".
All uses updated.
(dwarf2_start_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dwarf_decode_macros): Delete comp_dir argument. All callers updated.
(struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
(dw2_instantiate_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dw2_find_last_source_symtab): Ditto.
(dw2_lookup_symbol): Ditto.
(recursively_find_pc_sect_compunit_symtab): Renamed from
recursively_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(dw2_find_pc_sect_compunit_symtab): Renamed from
dw2_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(get_compunit_symtab): Renamed from get_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(recursively_compute_inclusions): Change type of immediate_parent
argument to "struct compunit_symtab *". All callers updated.
(compute_compunit_symtab_includes): Renamed from
compute_symtab_includes. All callers updated. Rewrite to compute
includes of compunit_symtabs and not symtabs.
(process_full_comp_unit): Update to work with struct compunit_symtab.
(process_full_type_unit): Ditto.
(dwarf_decode_lines_1): Delete argument comp_dir. All callers updated.
(dwarf_decode_lines): Remove special case handling of main subfile.
(macro_start_file): Delete argument comp_dir. All callers updated.
(dwarf_decode_macro_bytes): Ditto.
* guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to
use struct compunit_symtab.
* i386-tdep.c (i386_skip_prologue): Fetch producer from compunit.
* jit.c (finalize_symtab): Build compunit_symtab.
* jv-lang.c (get_java_class_symtab): Change result to
"struct compunit_symtab *". All callers updated.
* macroscope.c (sal_macro_scope): Fetch macro table from compunit.
* macrotab.c (struct macro_table) <compunit_symtab>: Renamed from
comp_dir. Change type to "struct compunit_symtab *".
All uses updated.
(new_macro_table): Change comp_dir argument to cust,
"struct compunit_symtab *". All callers updated.
* maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from
nr_primary_symtabs. All uses updated.
(count_symtabs_and_blocks): Update to handle compunits.
(report_command_stats): Update output, "primary symtabs" renamed to
"compunits".
* mdebugread.c (new_symtab): Change result to
"struct compunit_symtab *". All callers updated.
(parse_procedure): Change type of search_symtab argument to
"struct compunit_symtab *". All callers updated.
* objfiles.c (objfile_relocate1): Loop over blockvectors in a
separate loop.
* objfiles.h (struct objfile) <compunit_symtabs>: Renamed from
symtabs. Change type to "struct compunit_symtab *". All uses updated.
(ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS.
All uses updated.
(ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS.
All uses updated.
(ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated.
(ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated.
* psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
* psymtab.c (psymtab_to_symtab): Change result type to
"struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab_from_partial): Renamed from
find_pc_sect_symtab_from_partial. Change result type to
"struct compunit_symtab *". All callers updated.
(lookup_symbol_aux_psymtabs): Change result type to
"struct compunit_symtab *". All callers updated.
(find_last_source_symtab_from_partial): Ditto.
* python/py-symtab.c (stpy_get_producer): Fetch producer from compunit.
* source.c (forget_cached_source_info_for_objfile): Fetch debugformat
and macro_table from compunit.
* symfile-debug.c (debug_qf_find_last_source_symtab): Change result
type to "struct compunit_symtab *". All callers updated.
(debug_qf_lookup_symbol): Ditto.
(debug_qf_find_pc_sect_compunit_symtab): Renamed from
debug_qf_find_pc_sect_symtab, change result type to
"struct compunit_symtab *". All callers updated.
* symfile.c (allocate_symtab): Delete objfile argument.
New argument cust.
(allocate_compunit_symtab): New function.
(add_compunit_symtab_to_objfile): New function.
* symfile.h (struct quick_symbol_functions) <lookup_symbol>:
Change result type to "struct compunit_symtab *". All uses updated.
<find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All uses updated.
* symmisc.c (print_objfile_statistics): Compute blockvector count in
separate loop.
(dump_symtab_1): Update test for primary source symtab.
(maintenance_info_symtabs): Update to handle compunit symtabs.
(maintenance_check_symtabs): Ditto.
* symtab.c (set_primary_symtab): Delete.
(compunit_primary_filetab): New function.
(compunit_language): New function.
(iterate_over_some_symtabs): Change type of arguments "first",
"after_last" to "struct compunit_symtab *". All callers updated.
Update to loop over symtabs in each compunit.
(error_in_psymtab_expansion): Rename symtab argument to cust,
and change type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_compunit_symtab): Renamed from find_pc_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_line): Only loop over symtabs within selected compunit
instead of all symtabs in the objfile.
* symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab.
<compunit_symtab> New member.
<block_line_section>: Moved to compunit_symtab.
<locations_valid>: Ditto.
<epilogue_unwind_valid>: Ditto.
<macro_table>: Ditto.
<dirname>: Ditto.
<debugformat>: Ditto.
<producer>: Ditto.
<objfile>: Ditto.
<call_site_htab>: Ditto.
<includes>: Ditto.
<user>: Ditto.
<primary>: Delete
(SYMTAB_COMPUNIT): New macro.
(SYMTAB_BLOCKVECTOR): Update definition.
(SYMTAB_OBJFILE): Update definition.
(SYMTAB_DIRNAME): Update definition.
(struct compunit_symtab): New type. Common members among all source
symtabs within a compilation unit moved here. All uses updated.
(COMPUNIT_OBJFILE): New macro.
(COMPUNIT_FILETABS): New macro.
(COMPUNIT_DEBUGFORMAT): New macro.
(COMPUNIT_PRODUCER): New macro.
(COMPUNIT_DIRNAME): New macro.
(COMPUNIT_BLOCKVECTOR): New macro.
(COMPUNIT_BLOCK_LINE_SECTION): New macro.
(COMPUNIT_LOCATIONS_VALID): New macro.
(COMPUNIT_EPILOGUE_UNWIND_VALID): New macro.
(COMPUNIT_CALL_SITE_HTAB): New macro.
(COMPUNIT_MACRO_TABLE): New macro.
(ALL_COMPUNIT_FILETABS): New macro.
(compunit_symtab_ptr): New typedef.
(DEF_VEC_P (compunit_symtab_ptr)): New vector type.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Update expected output.
Jan noticed that gdb.ada/arrayidx.exp regressed after I applied
the following patch:
commit 8908fca577
Author: Joel Brobecker <brobecker@adacore.com>
Date: Sat Sep 27 09:09:34 2014 -0700
Subject: [Ada] Ignore __XA types when redundant.
What happens is that we're trying to print the value of
r_two_three, which is defined as follow:
type Index is (One, Two, Three);
type RTable is array (Index range Two .. Three) of Integer;
R_Two_Three : RTable := (2, 3);
The expected output is:
(gdb) p r_two_three
$1 = (two => 2, 3)
But after the patch above was applied, with the program program
compiled using gcc-gnat-4.9.2-1.fc21.x86_64 (x86_64-linux),
the output becomes:
(gdb) p r_two_three
$1 = (2, 3)
(the name of the first bound is missing). The problem comes from
the fact that the compiler described the array's index type as
a plain base type, instead of as a subrange of the enumerated type.
More particularly, this is what gcc-gnat-4.9.2-1.fc21.x86_64
generated:
<3><7ce>: Abbrev Number: 9 (DW_TAG_array_type)
<7cf> DW_AT_name : (indirect string, offset: 0xc13): p__rtable
[...]
<7d7> DW_AT_GNAT_descriptive_type: <0x98a>
[...]
<4><7df>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7e0> DW_AT_type : <0xa79>
where DIE 0xa79 is:
<1><a79>: Abbrev Number: 2 (DW_TAG_base_type)
<a7a> DW_AT_byte_size : 8
<a7b> DW_AT_encoding : 7 (unsigned)
<a7c> DW_AT_name : (indirect string, offset: 0xfc): sizetype
The actual array subrange type can be found in the array's
parallel XA type (the DW_AT_GNAT_descriptive_type).
The recent commit correctly found that that bounds taken from
the descriptive type are the same as bounds of our array's index
type. But it failed to notice that ignoring this descriptive
type would make us lose the actual array index type, making us
think that we're printing an array indexed by integers.
I hadn't seen that problem, because the compiler I used produced
debugging info where the array's index type is correctly described:
<3><79f>: Abbrev Number: 10 (DW_TAG_array_type)
<7a0> DW_AT_name : (indirect string, offset: 0xb3d): p__rtable
[...]
<4><7b0>: Abbrev Number: 8 (DW_TAG_subrange_type)
<7b1> DW_AT_type : <0x9b2>
<7b5> DW_AT_upper_bound : 2
... where DIE 0x9b2 leads us to ...
<3><9b2>: Abbrev Number: 9 (DW_TAG_subrange_type)
[...]
<9b8> DW_AT_type : <0x962>
<2><962>: Abbrev Number: 22 (DW_TAG_enumeration_type)
<963> DW_AT_name : (indirect string, offset: 0xb34): p__index
[...]
This patch fixes the issue by also making sure that the subtype
of the original range type does match the subtype found in the
descriptive type.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): Return 0
if the TYPE_CODE of range_type's base type does not match
the TYPE_CODE of encoding_type's base type.
The bp-permanent test case assumes that a NOP is exactly as long as a
software breakpoint. This is not the case for the S390 "nop"
instruction, which is 4 bytes long, while a software breakpoint is
just 2 bytes long. The "nopr" instruction has the right size and can
be used instead.
Without this patch the test case fails on S390 when trying to continue
after SIGTRAP on the permanent breakpoint:
...
Continuing.
Program received signal SIGILL, Illegal instruction.
test () at /home/arnez/src/binutils-gdb/gdb/testsuite/gdb.base/bp-permanent.c:40
40 NOP; /* after permanent bp */
(gdb)
FAIL: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0:
basics: stop at permanent breakpoint
With this patch the test case succeeds without any FAILs.
gdb/testsuite/ChangeLog:
* gdb.base/bp-permanent.c (NOP): Define as 2-byte instead of
4-byte instruction on S390.
Using the example in gdb.ada/complete.exp, the following command
on x86_64-windows returns one unwanted completion choice :
(gdb) complete p pck
p <pck_E>>
[all following completions entries snipped, all expected]
I tracked down this suprising entry to a minimal symbol whose name
is ".refptr.pck_E". The problem occurs while trying to see if
this symbol matches "pck" when doing wild-matching as we are doing
here:
/* Second: Try wild matching... */
if (!match && wild_match_p)
{
/* Since we are doing wild matching, this means that TEXT
may represent an unqualified symbol name. We therefore must
also compare TEXT against the unqualified name of the symbol. */
sym_name = ada_unqualified_name (ada_decode (sym_name));
if (strncmp (sym_name, text, text_len) == 0)
match = 1;
}
What happens is that ada_decode correctly identifies the fact that
SYM_NAME (".refptr.pck_E") is not following any GNAT encoding, and
therefore returns that same name, but bracketed: "<.refptr.pck_E>".
This is the convention we use for telling GDB that the decoded name
is not a real Ada name - and therefore should not be encoded for
operations such as name matching, symbol lookups, etc. So far, so good.
Next is the call to ada_unqualified_name, which unfortunately does
not notice that the decoded name it is being given isn't a natural
symbol, and just blindly strips everything up to the last do, returning
"pck_E>". And of course, "pck_E>" matches "pck" now, and so we end
up accepting this symbol as a match.
This patch fixes the problem by making ada_unqualified_name a little
smarter by making sure that the given decoded symbol name does not
start with '<'.
gdb/ChangeLog:
* ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
it starts with '<'.
Tested on x86_64-windows using AdaCore's testsuite as well as
on x86_64-linux.
Consider the following code which declares a variable A2 which
is an array of arrays of integers.
type Array2_First is array (24 .. 26) of Integer;
type Array2_Second is array (1 .. 2) of Array2_First;
A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));
Trying to print the type of that variable currently yields:
(gdb) ptype A2
type = array (1 .. 2, 24 .. 26) of integer
This is not correct, as this is the description of a two-dimension
array, which is different from an array of arrays. The expected
output is:
(gdb) ptype a2
type = array (1 .. 2) of foo_n926_029.array2_first
GDB's struct type currently handles multi-dimension arrays the same
way arrays of arrays, where each dimension is stored as a sub-array.
The ada-valprint module considers that consecutive array layers
are in fact multi-dimension arrays. For array of arrays, a typedef
layer is introduced between the two arrays, creating a break between
each array type.
In our situation, A2 is a described as a typedef of an array type...
.uleb128 0x8 # (DIE (0x125) DW_TAG_variable)
.ascii "a2\0" # DW_AT_name
.long 0xfc # DW_AT_type
.uleb128 0x4 # (DIE (0xfc) DW_TAG_typedef)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0x107 # DW_AT_type
.uleb128 0x5 # (DIE (0x107) DW_TAG_array_type)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0xb4 # DW_AT_type
.uleb128 0x6 # (DIE (0x114) DW_TAG_subrange_type)
.long 0x11b # DW_AT_type
.byte 0x2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x107
... whose element type is, as expected, a typedef to the sub-array
type:
.uleb128 0x4 # (DIE (0xb4) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xbf # DW_AT_type
.uleb128 0x9 # (DIE (0xbf) DW_TAG_array_type)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xd8 # DW_AT_GNAT_descriptive_type
.long 0x1c5 # DW_AT_type
.uleb128 0xa # (DIE (0xd0) DW_TAG_subrange_type)
.long 0xf0 # DW_AT_type
.byte 0x18 # DW_AT_lower_bound
.byte 0x1a # DW_AT_upper_bound
.byte 0 # end of children of DIE 0xbf
The reason why things fails is that, during expression evaluation,
GDB tries to "fix" A1's type. Because the sub-array has a parallel
(descriptive) type (DIE 0xd8), GDB thinks that our array's index
type must be dynamic and therefore needs to be fixed. This in turn
causes the sub-array to be "fixed", which itself results in the
typedef layer to be stripped.
However, looking closer at the parallel type, we see...
.uleb128 0xb # (DIE (0xd8) DW_TAG_structure_type)
.long .LASF8 # DW_AT_name: "foo__array2_first___XA"
[...]
.uleb128 0xc # (DIE (0xe4) DW_TAG_member)
.long .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"
... that all it tells us is that the array bounds are 24 and 26,
which is already correctly provided by the array's DW_TAG_subrange_type
bounds, meaning that this parallel type is just redundant.
Parallel types in general are slowly being removed in favor of
standard DWARF constructs. But in the meantime, this patch kills
two birds with one stone:
1. It recognizes this situation where the XA type is useless,
and saves an unnecessary range-type fixing;
2. It fixes the issue at hand because ignoring the XA type results
in no type fixing being required, which allows the typedef layer
to be preserved.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): New function.
(ada_is_redundant_index_type_desc): New function.
(to_fixed_array_type): Ignore parallel XA type if redundant.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_arr: New testcase.
Tested on x86_64-linux.
... when that packed array is part of a discriminated record and
one of the bounds is a discriminant.
Consider the following code:
type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
pragma PACK (FUNNY_STR_T);
type FUNNY_STRING_T (SIZE : NATURAL := 1) is
record
STR : FUNNY_STR_T (1 .. SIZE) := (others => '0');
LENGTH : NATURAL := 4;
end record;
TEST: FUNNY_STRING_T(100);
GDB is able to print the value of variable "test" and "test.str".
But not "test.str(1)":
(gdb) p test
$1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
(gdb) p test.str
$2 = (33 'A', nul <repeats 99 times>)
(gdb) p test.str(1)
object size is larger than varsize-limit
The problem occurs during the phase where we are trying to resolve
the expression subscript operation. On the one hand of the subscript
operator, we have the result of the evaluation of "test.str", which
is our packed array. We have the following code to handle packed
arrays in particular:
if (ada_is_constrained_packed_array_type
(desc_base_type (value_type (argvec[0]))))
argvec[0] = ada_coerce_to_simple_array (argvec[0]);
This eventually leads to a call to constrained_packed_array_type
to return the "simple array". This function relies on a parallel
___XA type, when available, to determine the bounds. In our case,
we find type...
failure__funny_string_t__T4b___XA"
... which has one field describing the bounds of our array as:
failure__funny_string_t__T3b___XDLU_1__size
The part that interests us is after the ___XD suffix or,
in other words: "LU_1__size". What this means in GNAT encoding
parlance is that the lower bound is 1, and that the upper bound
is the value of "size". "size" is our discriminant in this case.
Normally, we would access the record's discriminant in order to
get the upper bound's value, but we do not have that information,
here. We are in a mode where we are just trying to "fix" the type
without an actual value. This is what the call to to_fixed_range_type
is doing, and because the fix'ing fails, it ends up returning
the ___XDLU type unmodified as our index type.
This shouldn't be a problem, except that the later part of
constrained_packed_array_type then uses that index_type to
determine the array size, via a call to get_discrete_bounds.
The problem is that the upper bound of the ___XDLU type is
dynamic (in the DWARF sense) while get_discrete_bounds implicitly
assumes that the bounds are static, and therefore accesses
them using macros that assume the bounds values are constants:
case TYPE_CODE_RANGE:
*lowp = TYPE_LOW_BOUND (type);
*highp = TYPE_HIGH_BOUND (type);
This therefore returns a bogus value for the upper bound,
leading to an unexpectedly large size for our array, which
later triggers the varsize-limit guard we've seen above.
This patch avoids the problem by adding special handling
of dynamic range types. It also extends the documentation
of the constrained_packed_array_type function to document
what happens in this situation.
gdb/ChangeLog:
* ada-lang.c (constrained_packed_array_type): Set the length
of the return array as if both bounds where zero if that
returned array's index type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/pkd_arr_elem: New Testcase.
Tested on x86_64-linux.
I cross-compile gdb for msdosdjgpp (both target and host is
i586-pc-msdosdjgpp), so the CC should be i586-pc-msdosdjgpp-gcc.
However, CC is set incorrectly to gcc after config/i386/go32.mh is inlined
into the Makefile.
This patch is to remove the CC setting in config/i386/go32.mh.
gdb:
2014-11-19 Yao Qi <yao@codesourcery.com>
* config/i386/go32.mh (CC): Remove.
This patch is conceptually quite simple.
If you look at end_symtab_from_static_block you'll see
that the static_block == NULL case is completely different
than the non-NULL case.
There's a lot of complexity to handle the NULL case but it seems
entirely unnecessary. For example, whether blockvector is NULL
is decided at the start, before this for loop:
for (subfile = subfiles; subfile; subfile = nextsub)
Secondly, after the for loop, we test symtab for non-NULL here:
/* Set this for the main source file. */
if (symtab)
but symtab will only ever be non-NULL if blockvector was non-NULL.
And if blockvector was non_NULL so will symtab.
The other case to consider is these lines of code executed before
the for loop:
/* Read the line table if it has to be read separately.
This is only used by xcoffread.c. */
if (objfile->sf->sym_read_linetable != NULL)
objfile->sf->sym_read_linetable (objfile);
/* Handle the case where the debug info specifies a different path
for the main source file. It can cause us to lose track of its
line number information. */
watch_main_source_file_lossage ();
From my reading of the code, neither of these is useful
in the static_block == NULL case.
Thus we can make the code more readable by splitting these two cases up,
which is what this patch does.
gdb/ChangeLog:
* buildsym.c (main_subfile): New static global.
(free_subfiles_list): New function.
(start_symtab): Set main_subfile.
(restart_symtab): Replace init of subfiles, current_subfile with
call to free_subfiles_list.
(watch_main_source_file_lossage): Use main_subfile.
(reset_symtab_globals): Replace init of current_subfile with call
to free_subfiles_list.
(end_symtab_without_blockvector, end_symtab_with_blockvector): New
functions, split out from ...
(end_symtab_from_static_block): ... here. Rewrite to call them.
gdb/ChangeLog:
* dwarf2read.c (dw2_instantiate_symtab): Add assert.
(dw2_lookup_symbol): Remove unnecessary test for primary symbol table.
* psymtab.c (lookup_symbol_aux_psymtabs): Ditto.
(psymtab_to_symtab): Add comment and assert.
(map_matching_symbols_psymtab): Remove unnecessary test for
non-primary symtab.
tests.
FAIL: gdb.reverse/consecutive-precsave.exp: reload precord save file
FAIL: gdb.reverse/finish-precsave.exp: reload precord save file
FAIL: gdb.reverse/until-precsave.exp: reload core file
FAIL: gdb.reverse/watch-precsave.exp: reload core file
FAIL: gdb.reverse/step-precsave.exp: reload core file
FAIL: gdb.reverse/break-precsave.exp: reload precord save file
FAIL: gdb.reverse/sigall-precsave.exp: reload precord save file
They happen for two reasons.
- mingw32 does not define SIGTRAP, so upon recording a core file, the
signal information will be missing, which in turn causes GDB to not
display the stopping signal when it loads the same core file. An
earlier message warns about this:
"warning: Signal SIGTRAP does not exist on this system."
- The testcase is crafted in a way that expects a pattern of the
stopping signal message instead of a successful core file read message.
The following patch fixes this by changing the old pattern to a more
reasonable one, while still ignoring the fact that mingw32-based GDB
does not record a SIGTRAP in a core file because it does not define
it.
gdb/testsuite/
2014-11-18 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/break-precsave: Expect completion message for
core file reads.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
Fix some more C compiler warnings for missing function return types
and implicit function declarations in the GDB testsuite.
gdb/testsuite/ChangeLog:
* gdb.base/bp-permanent.c: Include unistd.h.
* gdb.python/py-framefilter-mi.c (main): Add return type.
* gdb.python/py-framefilter.c (main): Likewise.
* gdb.trace/actions-changed.c (main): Likewise.
Remove literal line numbers from the regexps in mi-until.exp. Add
appropriate eye-catchers to until.c and refer to those instead.
This change fixes the test case after having disturbed the line
numbering with the previous fix for compiler warnings with -std=gnu11.
gdb/testsuite/ChangeLog:
* gdb.mi/until.c: Add eye-catchers.
* gdb.mi/mi-until.exp: Refer to eye-catchers instead of literal
line numbers.
In some .exp files it was missed to remove the references to
eye-catchers like "set breakpoint 9 here" when the non-prototype
function header variants they belonged to were deleted. This patch
cleans this up.
gdb/testsuite/ChangeLog:
* gdb.base/condbreak.exp: Drop references to removed non-prototype
function header variants in break1.c.
* gdb.base/ena-dis-br.exp: Likewise.
* gdb.base/hbreak2.exp: Likewise.
* gdb.reverse/until-precsave.exp: Drop references to removed
non-prototype function header variants in ur1.c.
* gdb.reverse/until-reverse.exp: Likewise.
We noticed the following error on ppc-lynx178, using just about
any program:
(gdb) tar remote mytarget:4444
Remote debugging using mytarget:4444
0x000100c8 in _start ()
(gdb) b try
Breakpoint 1 at 0x10844: file try.adb, line 11.
(gdb) cont
Continuing.
!!!-> Cannot remove breakpoints because program is no longer writable.
!!!-> Further execution is probably impossible.
Breakpoint 1, try () at try.adb:11
11 Local : Integer := 18;
And, of course, trying to continue yielded the expected outcome:
(gdb) c
Continuing.
warning: Error removing breakpoint 1
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
It turns out that the problem is caused by an intentional test
against a variable with an undefined value. After GDB receives
notification of the inferior stopping, it tries to remove the
breakpoint by sending a memory-write packet ("X10844,4:9 ").
This leads us to lynx_write_memory, where it tries to split
the memory-write into chunks of 4 bytes. And, in order to handle
writes which are not aligned on word boundaries, we have the
following code:
if (skip > 0 || truncate > 0)
/* We need to read the memory at this address in order to preserve
the data that we are not overwriting. */
lynx_read_memory (addr, (unsigned char *) &buf, xfer_size);
if (errno)
return errno;
(the comment explains what the code is about).
Unfortunately, the not-so-glaring error that we've made here is
that we're checking ERRNO regardless of whether we've called
lynx_read_memory. In our case, because we are writing 4 bytes
aligned on a word boundary, we do not call lynx_read_memory and
therefore test an ERRNO with an undefined value.
gdb/gdbserver/ChangeLog:
* lynx-low.c (lynx_write_memory): Put lynx_read_memory and
corresponding ERRNO check in same block.
Dwarf::tu and Dwarf::cu allow selection of units with 64-bit offsets
through an option. When selected, unit size is encoded properly, but
offset to abbreviation unit is still encoded in a 4-byte field. This
patch fixes the problem.
Reproducer:
Dwarf::assemble "blah.s" {
tu {is_64 1 version 4 addr_size 8} 0x1122334455667788 the_type {
type_unit {} { the_type: }
}
cu {is_64 1 version 4 addr_size 8} {
compile_unit {{language @DW_LANG_C}} {}
}
}
gdb/testsuite:
* lib/dwarf.exp (Dwarf::cu, Dwarf::tu): Emit
${_cu_offset_size} bytes abbrev offset.
Basically the problem is that "symtab" is ambiguous.
Is it the primary symtab (where we canonically think of
blockvectors as being stored) or is it for a specific file
(where each file's line table is stored) ?
gdb_disassembly wants the symtab that contains the line table
but is instead getting the primary symtab.
gdb/ChangeLog:
PR symtab/17559
* symtab.c (find_pc_line_symtab): New function.
* symtab.h (find_pc_line_symtab): Declare.
* disasm.c (gdb_disassembly): Call find_pc_line_symtab instead of
find_pc_symtab.
* tui/tui-disasm.c (tui_set_disassem_content): Ditto.
* tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Ditto.
* tui/tui-source.c (tui_vertical_source_scroll): Ditto.
* tui/tui-win.c (make_visible_with_new_height): Ditto.
* tui/tui-winsource.c (tui_horizontal_source_scroll): Ditto.
(tui_display_main): Call find_pc_line_symtab instead of find_pc_line.
gdb/testsuite/ChangeLog:
PR symtab/17559
* gdb.base/line-symtabs.exp: New file.
* gdb.base/line-symtabs.c: New file.
* gdb.base/line-symtabs.h: New file.
This patch just renames one function.
Its only caller is in stack.c where we're printing a backtrace
with non-zero info_verbose and we want to make sure all the needed
symtabs are expanded before printing the backtrace
so that debug symbol reading messages don't pollute the backtrace.
I think the new name of the function makes clearer to the reader
what is going on.
gdb/ChangeLog:
* symtab.c (expand_symtab_containing_pc): Renamed from
find_pc_sect_symtab_via_partial. All callers updated.
One parenthesis is missing, and it causes a compilation error. This
patch is to fix it.
gdb:
2014-11-15 Yao Qi <yao@codesourcery.com>
* go32-nat.c (go32_create_inferior): Add missing parenthesis.
When trying to build gdbserver on ppc-lynx178, the compiler reports
while trying to compile gdbserver/ax.c that vsprintf is not declared.
Looking at my C99 reference manual (a draft), I see the following
synopsis:
#include <stdarg.h>
#include <stdio.h>
int vsprintf(char * restrict s, [etc]);
Looking at stdio.h on LynxOS-178, if found where vsprintf gets
declared:
#if defined(__varargs_h) || defined(__stdarg_h) \
|| defined(_VARARGS_H) || defined(_STDARG_H)
extern int vsprintf _AP((char *, const char *, va_list));
#endif
Digging further, I noticed that common-defs.h, which is included
via server.h, includes stdarg.h after including stdio, explaining
why vsprintf does not get declared in this case.
This patch fixes the problem by including stdarg.h before stdio.h.
gdb/ChangeLog:
* common/common-defs.h: Move <stdarg.h> #include ahead of
<stdio.h> #include.
Tested on x86_64-linux.
We're currently pulling gnulib's errno module as a dependency of some
other module. That provides an errno.h that defines EILSEQ to a
distinct value if the system's errno.h doesn't define it already.
However, GNU iconv does this:
/* Get errno declaration and values. */
#include <errno.h>
/* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
have EILSEQ in a different header. On these systems, define EILSEQ
ourselves. */
#ifndef EILSEQ
#define EILSEQ @EILSEQ@
#endif
That's in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/include/iconv.h.in
The "different header" mentioned is wchar.h. This is handled in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/m4/eilseq.m4
which defines @EILSEQ@ to ENOENT if EILSEQ isn't found in either
errno.h or wchar.h.
So if iconv sets errno to EILSEQ on such system's, it's really setting
it to ENOENT. And when we check for EILSEQ, we're checking for
gnulib's value. The result is we won't detect the error correctly.
As we dropped support for both SunOS 4 or old BSD/OS, maybe we don't
need to care about the wchar.h issue anymore. Still, AFAICS, gnulib's
m4/errno_h.m4 doesn't know that EILSEQ may be defined in wchar.h, and
so on such systems, ISTM gnulib ends up defining an incompatible
EILSEQ itself, but I think that should be fixed on the gnulib side, by
making it extract the EILSEQ value out of the system's wchar.h, like
GNU iconv does.
So that leaves handling the case of gnulib making up a EILSEQ value,
which we take as meaning the system really doesn't really define it,
which will be the same systems GNU iconv sets errno to ENOENT instead
of EILSEQ.
Looking at glibc's iconv it seems that ENOENT is never used there.
It seems it's safe to always treat ENOENT the same as EILSEQ.
The current EILSEQ definition under PHONY_ICONV is obviously stale as
gnulib garantees there's always a EILSEQ defined.
Tested on x86_64 Fedora 20.
gdb/
2014-11-14 Pedro Alves <palves@redhat.com>
* charset.c [PHONY_ICONV && !EILSEQ] (EILSEQ): Don't define.
[!PHONY_ICONV] (gdb_iconv): New function.
[!PHONY_ICONV] (iconv): Redefine to gdb_iconv.
The patch <https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html>
fixed dw2-ifort-parameter.exp on powerpc64 by adding some labels to
get the start and end address of function func. This should also fix the
fail on thumb mode, however, this style is quite specific to gcc, and
other compiler, such as clang, may not guarantee the order of global
asms and functions. The test fails with clang:
$ make check RUNTESTFLAGS='dw2-ifort-parameter.exp CC_FOR_TARGET=clang'
(gdb) p/x param^M
No symbol "param" in current context.^M
(gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param
With this patch applied, dw2-ifort-parameter.exp still passes for gcc
on arm thumb mode and popwerpc64, and it also passes for clang on
x86_linux.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-ifort-parameter.c: Remove inline asm.
(func): Add label func_label.
* gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble):
Replace low_pc and high_pc with MACRO_AT_range.
Replace name, low_pc and high_pc with MACRO_AT_func.
Hi,
I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode
(gdb) p p->f^M
No symbol "p" in current context.^M
(gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f
and the crash on powerpc64
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x7d82100810000828 in ?? ()
The cause of both is that we incorrectly set attribute low_pc, since
main isn't resolved to function start address on these targets.
In this patch, we replace attributes name, low_pc and high_pc with
MACRO_AT_func. The fail on thumb mode is fixed, and crash on
powerpc64 is fixed too.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp (Dwarf::assemble):
Replace name, low_pc and high_pc with MACRO_AT_func.
This patch is to use dwarf::assemble to generate debug information, and
remove implptr-optimized-out.S as a result.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp: Use Dwarf::assemble to
produce debug information.
* gdb.dwarf2/implptr-optimized-out.S: Removed.
On arm-none-eabi target thumb mode, I see the following fail,
p the_int^M
$2 = 99^M
(gdb) FAIL: gdb.dwarf2/dwz.exp: p the_int
and on powerpc64 target, we even can't get function main from object
file,
disassemble main^M
No function contains specified address.^M
(gdb) FAIL: gdb.dwarf2/dwz.exp: disassemble main
This patch is to use MACRO_AT_func attribute to get the main's start
address and end address correctly, and also remove some code dwz.exp
getting main's length. This patch fixes fails on both thumb mode and
powerpc64 target.
PASS: gdb.dwarf2/dwz.exp: p other_int
PASS: gdb.dwarf2/dwz.exp: p the_int
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Remove the code to compile main.c to
object and get function length.
(Dwarf::assemble): Replace name, low_pc and high_pc attributes
with MACRO_AT_func.
(top-level): Replace gdb_compile and clean_restart with
prepare_for_testing.
* gdb.dwarf2/main.c (main): Add label main_label.
This patch addes DW macro attributes MACRO_AT_func and MACRO_AT_range
in dwarf assembler, which emits "DW_AT_low_pc func_start addr" and
"DW_AT_high_pc func_end addr". func_start and func_end are computed
automatically by proc function_range.
These two attributes are pseudo attribute or macro attribute, which
means they are not standard dwarf attribute in dwarf spec. Then can
be substituted or expanded to standard attributes or macro attributes.
See details in the comments to them. Dwarf assembler is extended to
handle them.
Now the attributes name/low_pc/high_pc can be replaced with
MACRO_AT_func like this:
subprogram {
{name main}
{low_pc main_start addr}
{high_pc main_end addr}
}
becomes:
subprogram {
{MACRO_AT_func { main ${srcdir}/${subdir}/${srcfile} }}
}
users don't have to worry about the start and end of function main, and
they only need to add a label main_label in main.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* lib/dwarf.exp (function_range): New procedure.
(Dwarf::_handle_macro_at_func): New procedure.
(Dwarf::_handle_macro_at_range): New procedure.
(Dwarf): Handle MACRO_AT_func and MACRO_AT_range.
This patch is to move some code to a new procedure _handle_attribute,
which will be used in my following patches.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* lib/dwarf.exp (_handle_DW_TAG): Move some code to ...
(_handle_attribute): New procedure.
Remove old-style function header variants from sepdebug.c. Eliminate
references to the removed locations "breakpoint 9" and "breakpoint 13"
from sepdebug.exp.
gdb/testsuite/ChangeLog:
* gdb.base/sepdebug.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
* gdb.base/sepdebug.exp: Drop references to removed code.
Remove old-style function header variants from list0.h and list1.c.
Fill the removed lines with comments or empty lines, such that the
line numbering is undisturbed. Changes to the line numbering would
require heavy adjustments to list.exp, where many line numbers are
hard-coded, as well as a fair amount of knowledge about the source
code in and around certain lines. Thus the dependency on the line
numbering can not be eliminated so easily, and it may not even be a
useful goal for a "list" test case. Another option might be to adjust
the literal line numbers in list.exp, but even that is not as
straightforward as it may seem, since the test case expects certain
source lines to be exactly n lines apart.
gdb/testsuite/ChangeLog:
* gdb.base/list0.h: Remove #ifdef PROTOTYPES, keep prototyped
variant. Preserve original line numbering.
* gdb.base/list1.c: Likewise.
Remove old-style function headers from break.c and break1.c. Adjust
break.exp accordingly; in particular eliminate references to the
removed locations "breakpoint 9, 13, and 16" from break.exp.
gdb/testsuite/ChangeLog:
* gdb.base/break.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
* gdb.base/break1.c: Likewise.
* gdb.base/break.exp: Drop references to removed code.
The previous patch did not indent perform_all_tests() correctly after
moving the main logic into it, to avoid obscuring the functional
changes. This patch fixes the indentation.
gdb/testsuite/ChangeLog:
* gdb.base/callfuncs.exp (perform_all_tests): Re-indent.
In callfuncs.exp, compile callfuncs.c with and without C function
header prototypes and execute all tests after each compilation.
gdb/testsuite/ChangeLog:
* gdb.base/callfuncs.exp: Remove 'prototypes' variable. Move main
logic into perform_all_tests() and invoke it with and without
function header prototypes.
(do_function_calls): Remove conditional XFAIL for PR 5318.
(rerun_and_prepare): Remove duplicate code.
(perform_all_tests): New. Main logic moved here.
The C source file for the 'callfuncs' test case did not compile with
-DNO_PROTOTYPES or -DPROTOTYPES. This patch fixes various syntax
errors under #ifdef NO_PROTOTYPES and a small typo under #ifdef
PROTOTYPES.
gdb/testsuite/ChangeLog:
* gdb.base/callfuncs.c (t_float_many_args): Fix syntax error in
code guarded by #ifdef NO_PROTOTYPES.
(t_double_many_args): Likewise.
(DEF_FUNC_MANY_ARGS_1): Likewise.
(DEF_FUNC_VALUES_1): Likewise.
(t_structs_ldc): Renamed from t_structs_fc in conditional code
guarded by #ifdef PROTOTYPES.
Remove the literal line number from a regexp in mi-console.exp. Add
an appropriate eye-catcher to mi-console.c and refer to that instead.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-console.c: Add eye-catcher.
* gdb.mi/mi-console.exp (semihosted_string): Refer to eye-catcher
instead of literal line number.
Remove the literal line number from a regexp in shlib-call.exp. Add
an appropriate eye-catcher to shr2.c and refer to that instead.
gdb/testsuite/ChangeLog:
* gdb.base/shr2.c: Add eye-catcher.
* gdb.base/shlib-call.exp: Refer to eye-catcher instead of literal
line number.
Remove literal line numbers from the regexps in jump.exp. Add
appropriate eye-catchers to jump.c and refer to those instead.
gdb/testsuite/ChangeLog:
* gdb.base/jump.c: Add eye-catchers.
* gdb.base/jump.exp: Refer to eye-catchers instead of literal line
numbers.
Remove literal line numbers from the regexps in foll-exec.exp. Add
appropriate eye-catchers to foll-exec.c and execd-proc.c and refer to
those instead.
gdb/testsuite/ChangeLog:
* gdb.base/execd-prog.c: Add eye-catchers.
* gdb.base/foll-exec.c: Likewise.
* gdb.base/foll-exec.exp: Refer to eye-catchers instead of literal
line numbers.
Remove literal line numbers from the regexps in ending-run.exp. Add
appropriate eye-catchers to ending-run.c and refer to those instead.
gdb/testsuite/ChangeLog:
* gdb.base/ending-run.c: Add eye-catchers.
* gdb.base/ending-run.exp: Refer to eye-catchers instead of
literal line numbers.
Remove literal line numbers from the regexps in call-rt-st.exp. Add
appropriate eye-catchers to call-rt-st.c and refer to those instead.
gdb/testsuite/ChangeLog:
* gdb.base/call-rt-st.c: Add eye-catchers.
* gdb.base/call-rt-st.exp: Refer to eye-catchers instead of
literal line numbers.
Remove literal line numbers from the regexps in call-ar-st.exp. Add
appropriate eye-catchers to call-ar-st.c and refer to those instead.
gdb/testsuite/ChangeLog:
* gdb.base/call-ar-st.c: Add eye-catchers.
* gdb.base/call-ar-st.exp: Refer to eye-catchers instead of
literal line numbers.
Remove literal line numbers from the commands and regexps in dbx.exp.
Add appropriate eye-catchers to average.c and sum.c and refer to those
instead.
gdb/testsuite/ChangeLog:
* gdb.base/average.c: Add eye-catchers.
* gdb.base/sum.c: Likewise.
* gdb.base/dbx.exp: Use eye-catchers to determine line numbers for
regexps dynamically.
Remove literal line numbers from the regexps in so-impl-ld.exp. Add
appropriate eye-catchers to solib1.c and refer to those instead.
gdb/testsuite/ChangeLog:
* gdb.base/solib1.c: Add eye-catchers.
* gdb.base/so-impl-ld.exp: Match against eye-catchers instead of
literal line numbers.
As no place in the backends check cont_thread anymore, we can stop
setting and clearing it in places that resume the target and wait for
events. Instead simply clear it whenever a new GDB connects.
gdb/gdbserver/
2014-11-12 Pedro Alves <palves@redhat.com>
* server.c (cont_thread): Update comment.
(start_inferior, attach_inferior): No longer clear cont_thread.
(handle_v_cont): No longer set cont_thread.
(captured_main): Clear cont_thread each time a GDB connects.
There's code in linux_wait_1 that resumes all threads if the Hc thread
disappears. It's the wrong thing to do, as GDB has told GDBserver to
resume only one thread, because e.g., the user has scheduler-locking
enabled, or because GDB was stepping the program over a breakpoint.
Resuming all threads behind GDB's back can't be good in either case.
The right thing to do is to detect that that the (only) resumed thread
is gone, and let GDB know about it. The Linux backend is already
doing that nowadays, since:
commit fa96cb382c
Author: Pedro Alves <palves@redhat.com>
AuthorDate: Thu Feb 27 14:30:08 2014 +0000
Teach GDBserver's Linux backend about no unwaited-for children (TARGET_WAITKIND_NO_RESUMED).
The backend detects that all resumed threads have disappeared, and
returns TARGET_WAITKIND_NO_RESUMED to the core of GDBserver, which
then reports an error to GDB.
There's no need to frob the passed in ptid to wait for the continue
thread either -- linux_wait_for_event only returns events for resumed
threads.
The badness (of resuming threads) can actually be observed in the
testsuite, if we force-disable vCont support in GDBserver -- before
the patch, gdb.threads/no-unwaited-for-left.exp hangs if we disable
vCont:
(gdb) continue
Continuing.
FAIL: gdb.threads/no-unwaited-for-left.exp: continue to breakpoint: break-here (timeout)
... more cascading timeouts ....
After the patch, gdb.threads/no-unwaited-for-left.exp behaves the same
with or without vCont support:
(gdb) continue
Continuing.
[New Thread 32226]
[Switching to Thread 32226]
Breakpoint 2, thread_a (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:28
28 return 0; /* break-here */
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue to breakpoint: break-here
...
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 32222] #1 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
Overall, this is also good for getting rid of a RSP detail from the backend.
gdb/gdbserver/
2014-11-12 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Don't force a wait for the Hc
thread, and don't resume all threads if the Hc thread has exited.
The target->request_interrupt callback implements the handling for
ctrl-c. User types ctrl-c in GDB, GDB sends a \003 to the remote
target, and the remote targets stops the program with a SIGINT, just
like if the user typed ctrl-c in GDBserver's terminal.
The trouble is that using kill_lwp(signal_pid, SIGINT) sends the
SIGINT directly to the program's main thread. If that thread has
exited already, then that kill won't do anything.
Instead, send the SIGINT to the process group, just like GDB
does (see inf-ptrace.c:inf_ptrace_stop).
gdb.threads/leader-exit.exp is extended to cover the scenario. It
fails against GDBserver before the patch.
Tested on x86_64 Fedora 20, native and GDBserver.
gdb/gdbserver/
2014-11-12 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_request_interrupt): Always send a SIGINT to
the process group instead of to a specific LWP.
gdb/testsuite/
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.threads/leader-exit.exp: Test sending ctrl-c works after the
leader has exited.
No longer used since the non-continuable watchpoints handling rework.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (enum infwait_states, infwait_state): Delete.
The gdb.arch/i386-bp_permanent.exp test is currently failing an
assertion recently added:
(gdb) stepi
../../src/gdb/infrun.c:2237: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.arch/i386-bp_permanent.exp: Single stepping past permanent breakpoint. (GDB internal error)
The assertion expects that the only reason we currently need to step a
breakpoint instruction is when we have a signal to deliver. But when
stepping a permanent breakpoint (with or without a signal) we also
reach this code.
The assertion is correct and the permanent breakpoints skipping code
is wrong.
Consider the case of the user doing "step/stepi" when stopped at a
permanent breakpoint. GDB's `resume' calls the
gdbarch_skip_permanent_breakpoint hook and then happily continues
stepping:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
}
But since gdbarch_skip_permanent_breakpoint already advanced the PC
manually, this ends up executing the instruction that is _after_ the
breakpoint instruction. The user-visible result is that a single-step
steps two instructions.
The gdb.arch/i386-bp_permanent.exp test is actually ensuring that
that's indeed how things work. It runs to an int3 instruction, does
"stepi", and checks that "leave" was executed with that "stepi". Like
this:
(gdb) b *0x0804848c
Breakpoint 2 at 0x804848c
(gdb) c
Continuing.
Breakpoint 2, 0x0804848c in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
=> 0x0804848c <+4>: int3
0x0804848d <+5>: leave
0x0804848e <+6>: ret
0x0804848f <+7>: nop
(gdb) si
0x0804848e in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
0x0804848c <+4>: int3
0x0804848d <+5>: leave
=> 0x0804848e <+6>: ret
0x0804848f <+7>: nop
End of assembler dump.
(gdb)
One would instead expect that a stepi at 0x0804848c stops at
0x0804848d, _before_ the "leave" is executed. This commit changes GDB
this way. Care is taken to make stepping into a signal handler when
the step starts at a permanent breakpoint instruction work correctly.
The patch adjusts gdb.arch/i386-bp_permanent.exp in this direction,
and also makes it work on x86_64 (currently it only works on i*86).
The patch also adds a new gdb.base/bp-permanent.exp test that
exercises many different code paths related to stepping permanent
breakpoints, including the stepping with signals cases. The test uses
"hack/trick" to make it work on all (or most) platforms -- it doesn't
really hard code a breakpoint instruction.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Clear the thread's 'stepped_breakpoint' flag.
Rewrite stepping over a permanent breakpoint.
(thread_still_needs_step_over, proceed): Don't set
stepping_over_breakpoint for permanent breakpoints.
(handle_signal_stop): Don't clear stepped_breakpoint. Also pull
single-step breakpoints out of the target on hardware step
targets.
(process_event_stop_test): If stepping a permanent breakpoint
doesn't hit the step-resume breakpoint, delete the step-resume
breakpoint.
(switch_back_to_stepped_thread): Also check if the stepped thread
has advanced already on hardware step targets.
(currently_stepping): Return true if the thread stepped a
breakpoint.
gdb/testsuite/
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-bp_permanent.c: New file.
* gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64.
(srcfile): Set to i386-bp_permanent.c.
(top level): Adjust to work in both 32-bit and 64-bit modes. Test
that stepi does not execute the 'leave' instruction, instead of
testing it does execute.
* gdb.base/bp-permanent.c: New file.
* gdb.base/bp-permanent.exp: New file.
"permanent"-ness is currently a property of the breakpoint. But, it
should actually be an implementation detail of a _location_. Consider
this bit in infrun.c:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
if (gdbarch_skip_permanent_breakpoint_p (gdbarch))
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
else
error (_("\
The program is stopped at a permanent breakpoint, but GDB does not know\n\
how to step past a permanent breakpoint on this architecture. Try using\n\
a command like `return' or `jump' to continue execution."));
}
This will wrongly skip a non-breakpoint instruction if we have a
multiple location breakpoint where the whole breakpoint was set to
"permanent" because one of the locations happened to be permanent,
even if the one GDB is resuming from is not.
Related, because the permanent breakpoints are only marked as such in
init_breakpoint_sal, we currently miss marking momentary breakpoints
as permanent. A test added by a following patch trips on that.
Making permanent-ness be per-location, and marking locations as such
in add_location_to_breakpoint, the natural place to do this, fixes
this issue...
... and then exposes a latent issue with mark_breakpoints_out. It's
clearing the inserted flag of permanent breakpoints. This results in
assertions failing like this:
Breakpoint 1, main () at testsuite/gdb.base/callexit.c:32
32 return 0;
(gdb) call callexit()
[Inferior 1 (process 15849) exited normally]
gdb/breakpoint.c:12854: internal-error: allegedly permanent breakpoint is not actually inserted
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The call dummy breakpoint, which is a momentary breakpoint, is set on
top of a manually inserted breakpoint instruction, and so is now
rightfully marked as a permanent breakpoint. See "Write a legitimate
instruction at the point where the infcall breakpoint is going to be
inserted." comment in infcall.c.
Re. make_breakpoint_permanent. That's only called by solib-pa64.c.
Permanent breakpoints were actually originally invented for HP-UX [1].
I believe that that call (the only one in the tree) is unnecessary
nowadays, given that nowadays the core breakpoints code analyzes the
instruction under the breakpoint to automatically detect whether it's
setting a breakpoint on top of a breakpoint instruction in the
program. I know close to nothing about HP-PA/HP-UX, though.
[1] https://sourceware.org/ml/gdb-patches/1999-q3/msg00245.html, and
https://sourceware.org/ml/gdb-patches/1999-q3/msg00242.html
In addition to the per-location issue, "permanent breakpoints" are
currently always displayed as enabled=='n':
(gdb) b main
Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
3 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
But OTOH they're always enabled; there's no way to disable them...
In turn, this means that if one adds commands to such a breakpoint,
they're _always_ run:
(gdb) start
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
...
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
(gdb) b main
Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "hello!"
>end
(gdb) disable 2
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
"hello!"(gdb)
IMO, one should be able to disable such a breakpoint, and GDB should
then behave just like if the user hadn't created the breakpoint in the
first place (that is, report a SIGTRAP).
By making permanent-ness a property of the location, and eliminating
the bp_permanent enum enable_state state ends up fixing that as well.
No tests are added for these changes yet; they'll be added in a follow
up patch, as skipping permanent breakpoints is currently broken and
trips on an assertion in infrun.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2014-11-12 Pedro Alves <palves@redhat.com>
Mark locations as permanent, not the whole breakpoint.
* breakpoint.c (remove_breakpoint_1, remove_breakpoint): Adjust.
(mark_breakpoints_out): Don't mark permanent breakpoints as
uninserted.
(breakpoint_init_inferior): Use mark_breakpoints_out.
(breakpoint_here_p): Adjust.
(bpstat_stop_status, describe_other_breakpoints): Remove handling
of permanent breakpoints.
(make_breakpoint_permanent): Mark each location as permanent,
instead of marking the breakpoint.
(add_location_to_breakpoint): If the location is permanent, mark
it as such, and as inserted.
(init_breakpoint_sal): Don't make the breakpoint permanent here.
(bp_location_compare, update_global_location_list): Adjust.
(update_breakpoint_locations): Don't make the breakpoint permanent
here.
(disable_breakpoint, enable_breakpoint_disp): Don't skip permanent
breakpoints.
* breakpoint.h (enum enable_state) <bp_permanent>: Delete field.
(struct bp_location) <permanent>: New field.
* guile/scm-breakpoint.c (bpscm_enable_state_to_string): Remove
reference to bp_permanent.
breakpoint.c uses gdbarch_breakpoint_from_pc to determine whether a
breakpoint location points at a permanent breakpoint:
static int
bp_loc_is_permanent (struct bp_location *loc)
{
...
addr = loc->address;
bpoint = gdbarch_breakpoint_from_pc (loc->gdbarch, &addr, &len);
...
if (target_read_memory (loc->address, target_mem, len) == 0
&& memcmp (target_mem, bpoint, len) == 0)
retval = 1;
...
So I think we should default the gdbarch_skip_permanent_breakpoint
hook to advancing the PC by the length of the breakpoint instruction,
as determined by gdbarch_breakpoint_from_pc. I believe that simple
implementation does the right thing for most architectures. If
there's an oddball architecture where that doesn't work, then it
should override the hook, just like it should be overriding the hook
if there was no default anyway.
The only two implementation of skip_permanent_breakpoint are
i386_skip_permanent_breakpoint, for x86, and
hppa_skip_permanent_breakpoint, for PA-RISC/HP-UX
The x86 implementation is trivial, and can clearly be replaced by the
new default.
I don't know about the HP-UX one though, I know almost nothing about
PA. It may well be advancing the PC ends up being equivalent.
Otherwise, it must be that "jump $pc_after_bp" doesn't work either...
Tested on x86_64 Fedora 20 native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_skip_permanent_breakpoint): New function.
* arch-utils.h (default_skip_permanent_breakpoint): New
declaration.
* gdbarch.sh (skip_permanent_breakpoint): Now an 'f' function.
Install default_skip_permanent_breakpoint as default method.
* i386-tdep.c (i386_skip_permanent_breakpoint): Delete function.
(i386_gdbarch_init): Don't install it.
* infrun.c (resume): Assume there's always a
gdbarch_skip_permanent_breakpoint implementation.
* gdbarch.h, gdbarch.c: Regenerate.
Linux supports multiple "PID namespaces". Processes in different PID
namespaces have different views of the system process list. Sometimes,
a single process can appear in more than one PID namespace, but with a
different PID in each. When GDB and its target are in different PID
namespaces, various features can break due to the mismatch between
what the target believes its PID to be and what GDB believes its PID
to be. The most visible broken functionality is thread enumeration
silently failing.
This patch explicitly warns users against trying to debug across PID
namespaces.
The patch introduced no new failures in my test suite run on an x86_64
installation of Ubuntu 14.10. It doesn't include a test: writing an
automated test that exercises this code would be very involved because
CLONE_NEWNS requires CAP_SYS_ADMIN; the easier way to reproduce the
problem is to start a new lxc container.
gdb/
2014-11-11 Daniel Colascione <dancol@dancol.org>
Warn about cross-PID-namespace debugging.
* nat/linux-procfs.h (linux_proc_pid_get_ns): New prototype.
* nat/linux-procfs.c (linux_proc_pid_get_ns): New function.
* linux-thread-db.c (check_pid_namespace_match): New function.
(thread_db_inferior_created): Call it.
When searching static symbols, gdb would search over all
expanded symtabs of all objfiles, and if that fails only then
would it search all partial/gdb_index tables of all objfiles.
This means that the user could get a random instance of the
symbol depending on what symtabs have been previously expanded.
Now the search is consistent, searching each objfile completely
before proceeding to the next one.
gdb/ChangeLog:
PR symtab/17564
* symtab.c (lookup_symbol_in_all_objfiles): Delete.
(lookup_static_symbol): Move definition to new location and rewrite.
(lookup_symbol_in_objfile): New function.
(lookup_symbol_global_iterator_cb): Call it.
gdb/testsuite/ChangeLog:
PR symtab/17564
* gdb.base/symtab-search-order.exp: New file.
* gdb.base/symtab-search-order.c: New file.
* gdb.base/symtab-search-order-1.c: New file.
* gdb.base/symtab-search-order-shlib-1.c: New file.
A recent change to eval.c triggered a GCC bug that causes a false positive
"may be used uninitialized" warning in evaluate_subexp_standard. This seems
to be triggered by a specific CFG constructed via setjmp and gotos.
While the GCC bug is in the process of being fixed, there are released
compiler versions (in particular GCC 4.9) in the field that show this
problem. In order to allow compiling GDB with one of those compilers,
this commit slightly reworks the CFG (in an equivalent way) of the
affected function, so that the GCC bug is no longer triggered.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Work around GCC bug 63748.
Running gdb.base/sigstep.exp with --target=i686-pc-linux-gnu on a
64-bit kernel naturally trips on PR gdb/17511 as well, given this is a
kernel bug.
I haven't really tested a real 32-bit kernel/machine, but given the
code in question in the kernel is shared between 32-bit and 64-bit,
I'm quite sure the bug triggers in those cases as well.
So, simply xfail i?86-*-linux* too.
gdb/testsuite/
2014-11-07 Pedro Alves <palves@redhat.com>
PR gdb/17511
* gdb.base/sigstep.exp (in_handler_map) <si+advance>: xfail
i?86-*-linux*.
The in_prologue check in the nexti code is obsolete; this commit
removes that, and then removes the in_prologue function as nothing
else uses it.
Looking at the code in GDB that makes use in_prologue, all we find is
this one caller:
if ((ecs->event_thread->control.step_over_calls == STEP_OVER_NONE)
|| ((ecs->event_thread->control.step_range_end == 1)
&& in_prologue (gdbarch, ecs->event_thread->prev_pc,
ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog, so we
thought it was a subroutine call but it was not. Stop as
well. FENN */
/* And this works the same backward as frontward. MVS */
end_stepping_range (ecs);
return;
}
This was added by:
commit 100a02e1de
...
From Fernando Nasser:
* infrun.c (handle_inferior_event): Handle "nexti" inside function
prologues.
The mailing list thread is here:
https://sourceware.org/ml/gdb-patches/2001-01/msg00047.html
Not much discussion there, and no test, but looking at the code around
what was patched in that revision, we see that the checks that detect
whether the program has just stepped into a subroutine didn't rely on
the unwinders at all back then.
From 'git show 100a02e1:gdb/infrun.c':
if (stop_pc == ecs->stop_func_start /* Quick test */
|| (in_prologue (stop_pc, ecs->stop_func_start) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!IN_SOLIB_RETURN_TRAMPOLINE (stop_pc, ecs->stop_func_name))
|| IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
if ((step_over_calls == STEP_OVER_NONE)
|| ((step_range_end == 1)
&& in_prologue (prev_pc, ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog,
so we thought it was a subroutine call but it was not.
Stop as well. FENN */
stop_step = 1;
print_stop_reason (END_STEPPING_RANGE, 0);
stop_stepping (ecs);
return;
}
Stripping the IN_SOLIB_RETURN_TRAMPOLINE checks for simplicity, we had:
if (stop_pc == ecs->stop_func_start /* Quick test */
|| in_prologue (stop_pc, ecs->stop_func_start)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
That is, detecting a subroutine call was based on prologue detection
back then. So the in_prologue check in the current tree only made
sense back then as it was undoing a bad decision the in_prologue check
that used to exist above did.
Today, the check for a subroutine call relies on frame ids instead,
which are stable throughout the function. So we can just remove the
in_prologue check for nexti, and the whole in_prologue function along
with it.
Tested on x86_64 Fedora 20, and also by nexti-ing manually a prologue.
gdb/
2014-11-07 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test) <subroutine check>: Don't
check if we did a "nexti" inside a prologue.
* symtab.c (in_prologue): Delete function.
* symtab.h (in_prologue): Delete declaration.
"aux" doesn't contribute anything to the name, and it makes the
reader wonder what it's supposed to mean.
gdb/ChangeLog:
* symtab.c (lookup_local_symbol): Renamed from lookup_symbol_aux_local.
All callers updated.
(lookup_symbol_in_all_objfiles): Renamed from
lookup_symbol_aux_symtabs. All callers updated.
(lookup_symbol_via_quick_fns): Renamed from lookup_symbol_aux_quick.
All callers updated.
(lookup_symbol_in_objfile_symtabs): Renamed from
lookup_symbol_aux_objfile. All callers updated.
and lookup_static_symbol_aux to lookup_static_symbol.
gdb/ChangeLog:
* symtab.c (lookup_static_symbol): Renamed from
lookup_static_symbol_aux. All callers updated.
(lookup_symbol_in_static_block): Renamed from lookup_symbol_static.
All callers updated.
gdb/ChangeLog:
* block.h (ALL_BLOCK_SYMBOLS_WITH_NAME): New macro.
* block.c (block_lookup_symbol): Use it.
* cp-support.c (make_symbol_overload_list_block): Use it.
* symtab.c (iterate_over_symbols): Use it.
There is another function, lookup_symbol_aux_block, and
the names lookup_block_symbol and lookup_symbol_aux_block don't
convey any real difference between them.
The difference is that lookup_block_symbol lives in the lower level
block API, and lookup_symbol_aux_block lives in the higher level symtab API.
This patch makes this distinction clear.
gdb/ChangeLog:
* symtab.c (lookup_block_symbol): Moved to ...
* block.c (block_lookup_symbol): ... here and renamed.
All callers updated.
* block.h (block_lookup_symbol): Declare.
* symtab.h (lookup_block_symbol): Delete.
Non-primary symtabs share the block vector with their primary symtabs.
In these cases there's no need to use ALL_SYMTABS.
gdb/ChangeLog:
* ada-lang.c (ada_make_symbol_completion_list): Use
ALL_PRIMARY_SYMTABS instead of ALL_SYMTABS.
* symtab.c (lookup_objfile_from_block): Ditto.
obstack_next_free is supposed to return a void*, rather than a char*
as it does currently. Avoid warning on void* arithmetic when
obstack_next_free gets it proper return type.
* cp-valprint.c (cp_print_value_fields): Cast obstack_next_free
to char* before doing pointer arithmetic.
obstack_blank isn't the correct macro to call for shrinking obstacks
since it does size checking.
* charset.c (convert_between_encodings): Shrink obstack using
obstack_blank_fast.
* minsyms.c (install_minimal_symbols): Likewise.
Older versions of ncurses' newterm can't take NULL for their ofp and ifp
parameters. Newer versions can, and they fall back on stdout/stdin if
that is the case.
This patch explicitly passes stdout/stdin to the call to newterm to
avoid segfaulting with older ncurses.
gdb/Changelog:
2014-11-04 Simon Marchi <simon.marchi@ericsson.com>
* tui/tui.c (tui_enable): Pass stdout and stdin to newterm.
Used to be necessary for the thread-hop code, but that's gone now.
Nothing uses this anymore.
gdb/
2014-11-04 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_thread_match): Delete function.
* breakpoint.h (breakpoint_thread_match): Delete declaration.
When evaluating method calls under EVAL_SKIP, the "object" and the
arguments to the method should also be evaluated under EVAL_SKIP,
instead of skipping to evaluate them as was being done previously.
gdb/ChangeLog:
PR c++/17494
* eval.c (evaluate_subexp_standard): Evaluate the "object" and
the method args also under EVAL_SKIP when evaluating method
calls under EVAL_SKIP.
gdb/testsuite/ChangeLog:
PR c++/17494
* gdb.cp/pr17494.cc: New file.
* gdb.cp/pr17494.exp: New file.
During armv7b testing gdb.base/store.exp test was failling with
'GDB internal error' with the following message:
Temporary breakpoint 1, wack_double (u=
../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
It turns out that compiler generated DWARF with non-existent
register numbers. The compiler issue is present in both little endian
(armv7) and big endian (armv7b) (it is separate issue). Here is
example for one of formal parameters of wack_double function:
<2><792>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<793> DW_AT_name : u
<795> DW_AT_decl_file : 1
<796> DW_AT_decl_line : 115
<797> DW_AT_type : <0x57c>
<79b> DW_AT_location : 6 byte block: 6d 93 4 6c 93 4 (DW_OP_reg29 (r29); DW_OP_piece: 4; DW_OP_reg28 (r28); DW_OP_piece: 4)
In both big and little endian cases gdbarch_dwarf2_reg_to_regnum
returns -1 which is stored into gdb_regnum. But it causes severe
problem only in big endian case because in read_pieced_value and
write_pieced_value functions BFD_ENDIAN_BIG related processing
happen regardless of gdb_regnum value, for example register_size
function is called and in case of gdb_regnum=-1, it cause
'GDB internal error' and crash.
Solution is to move BFD_ENDIAN_BIG related processing under
(gdb_regnum != -1) branch of processing.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* dwarf2loc.c (read_pieced_value): Do big endian
processing only if gdb_regnum is not -1.
(write_pieced_value): Ditto.
tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint
should be set le_ variants in case of arm BE8 code. Those instruciton
sequences are writen to target with simple write_memory, without
regarding gdbarch_byte_order_for_code. But in BE8 case even data
memory is in big endian form, instructions are still in little endian
form.
Because of this issue there are many issues while running gdb test
case in armv7b mode. For example gdb.arch/arm-disp-step.exp test fails
because it gets SIGILL when displaced instrucion sequence reaches
break instruction, which is in wrong byte order.
Solution is to set tdep->xxx_breakpoint sequences in BE8 case (i.e
when gdbarch_byte_order_for_code is BFD_ENDIAN_BIG.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* arm-linux-tdep.c (arm_linux_init_abi): Use
info.byte_order_for_code to choose endianity of breakpoint
instructions snippets.
extract_arm_insn function needs to read instructions in
gdbarch_byte_order_for_code byte order, because in case armv7b,
even data is big endian, instructions are still little endian.
Currently function uses gdbarch_byte_order which would be
big endian in armv7b case.
Because of this issue pretty much all gdb.reverse/ tests are
failing with 'Process record does not support instruction' message.
Fix is to change gdbarch_byte_order to gdbarch_byte_order_for_code,
when passed to extract_unsigned_integer that reads instruction.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* arm-tdep.c (extract_arm_insn): Use
gdbarch_byte_order_for_code to read arm instruction.
The test in gdb.python/python.exp tests "extended-prompt" and expects
working directory is printed. However, working directory on remote
host doesn't have "gdb/testsuite", so the test fails on remote host
like:
set extended-prompt \w ^M
^M
/home/yao FAIL: gdb.python/python.exp: set extended prompt working directory (timeout)
This patch is to get the working directory first, and use it to match
the output of "set extended-prompt \\w ". It works for remote host
and non remote host.
gdb/testsuite:
2014-11-02 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Get working directory and match the
output of "set extended-prompt \\w " with it.
Andreas Arnez
Simon Marchi
Ulrich Weigand
Yao Qi
Jan Kratochvil
Martin Galvan
Siva Chandra
Pierre Muller
Joel Brobecker
Doug Evans
Mark Wielaard
Sandra Loosemore
Samuel Thibault
Doug Evans
Patrick Palka
Sergio Durigan Junior
Luis Machado
Petr Machata
Pedro Alves
Daniel Colascione
Alan Modra
Victor Kamensky