This patch gives current stub-group-size in error message when stub
is too far away.
* aarch64.cc (Target_aarch64): Add new variable: stub_group_size_.
(AArch64_relocate_functions::maybe_apply_stub): Add new parameter.
Update error message.
(Target_aarch64::do_relax): Use absolute value of option
stub_group_size. Replace local variable with class member
stub_group_size_.
On Linux native, if dprintfs are inserted when detaching, they are left
in the inferior which causes it to crash from a SIGTRAP. It also happens
with dprintfs on remote targets, when set disconnected-dprintf is off.
The rationale of the line modified by the patch was to leave dprintfs
inserted in order to support disconnected dprintfs. However, not all
dprintfs are persistent. Also, there's no reason other kinds of
breakpoints can't be persistent either. So this replaces the bp_dprintf
check with a check on whether the location is persistent.
bl->target_info.persist will be 1 only if disconnected-dprintf is on and
we are debugging a remote target. On native, it will always be 0,
regardless of the value of disconnected-dprintf. This makes sense, since
disconnected dprintfs are not supported by the native target.
One issue about the test is that it does not pass when using
--target_board=native-extended-gdbserver, partly due to bug 17302 [1].
One quick hack I tried for this was to add a useless "next" between the
call to getpid() and detach, which avoids the bug. There is still one
case where the test fails, and that is with:
- breakpoint always-inserted on
- dprintf-style agent
- disconnected-dprintf on
What happens is that my detach does not actually detach the process,
because some persistent commands (the disconnected dprintf) is present.
However since gdbserver is ran with --once, when gdb disconnects,
gdbserver goes down and takes with it all the processes it spawned and
that are still under its control (which includes my test process).
When the test checks if the test process is still alive, it obvisouly
fails. Investigating about that led me to ask a question on the ML [2]
about the behavior of detach.
Until the remote case is sorted out, the problematic test is marked as
KFAIL.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17302
[2] https://sourceware.org/ml/gdb/2014-08/msg00115.html
gdb/Changelog:
PR breakpoints/17012
* breakpoint.c (remove_breakpoints_pid): Skip removing
breakpoint if it is marked as persistent.
gdb/testsuite/ChangeLog:
PR breakpoints/17012
* gdb.base/dprintf-detach.c: New file.
* gdb.base/dprintf-detach.exp: New file.
This patch introduces a function in gdbserver-support.exp to find out
whether the current target is GDBserver.
The code was inspired from gdb.trace/qtro.exp, so it replaces the code
there by a call to the new function.
gdb/testsuite/ChangeLog:
* gdb.trace/qtro.exp: Replace gdbserver detection code by...
* lib/gdb.exp (target_is_gdbserver): New
procedure.
When a thread exits, the terminal is left in mode "terminal_is_ours"
while the target executes. This patch fixes that.
We need to manually restore the terminal setting in this particular
observer. In the case of the other MI observers that call
target_terminal_ours, gdb will end up resuming the inferior later in the
execution and call target_terminal_inferior. In the case of the thread
exit event, we still need to call target_terminal_ours to be able to
print something, but there is nothing that gdb will need to resume after
that. We therefore need to call target_terminal_inferior ourselves.
gdb/ChangeLog:
PR gdb/17627
* target.c (cleanup_restore_target_terminal): New function.
(make_cleanup_restore_target_terminal): New function.
* target.h (make_cleanup_restore_target_terminal): New
declaration.
* mi/mi-interp.c (mi_thread_exit): Use the new cleanup.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
DW_AT_name for functions typically just contains the base function
name, so lacks namespace, class and parameter information. It would
be possible to extract all these from the DWARF, but at a considerable
complication of the parser in dwarf2.c, and then you'd need to mangle
it all together. Much simpler is to look up the actual symbol. This
patch does that, avoiding the extra symbol lookup when the language
doesn't do name mangling.
PR 17541
* dwarf2.c (struct comp_unit): Add "lang".
(non_mangled): New function.
(struct funcinfo): Add "is_linkage". Reorder for better packing.
Make "name" a const char*.
(lookup_address_in_function_table): Delete functionname_ptr param.
(find_abstract_instance_name): Add is_linkage param. Set if we
have DW_AT_linkage_name or non_mangled DW_AT_name.
(scan_unit_for_symbols): Similarly set func->is_linkage.
(parse_comp_unit): Stash DW_AT_language.
(comp_unit_find_nearest_line): Replace functionname_ptr param
with function_ptr param.
(_bfd_dwarf2_find_nearest_line): Adjust above calls. Set
functionname_ptr from function->name. Call _bfd_elf_find_function
to retrieve symbol for function if not linkage name.
(_bfd_elf_find_function): Add bfd_target_elf_flavour test, moved from..
* elf.c (elf_find_function): ..here.
(_bfd_elf_find_nearest_line): Adjust calls.
* elf-bfd.h (_bfd_elf_find_function): Declare.
_bfd_dwarf2_find_nearest_line may be called on a COFF bfd.
* dwarf2.c (read_address): Check bfd_target_elf_flavour before
calling get_elf_backend_data.
(_bfd_dwarf2_find_nearest_line): Fix parens.
HI16/LO16 are deliberately put adjacent, which might mean relocs are
then not sorted by r_offset. See tc-mips.c:mips_frob_file. Don't undo
the HI16/LO16 sorting.
PR 17666
* elf-bfd.h (struct elf_backend_data): Add sort_relocs_p.
* elfxx-target.h (elf_backend_sort_relocs_p): Define.
(elfNN_bed): Init new field.
* elflink.c (elf_link_adjust_relocs): Conditionally sort.
(bfd_elf_final_link): Control sorting of relocs.
* elfxx-mips.c (_bfd_mips_elf_sort_relocs_p): New function.
* elfxx-mips.h (_bfd_mips_elf_sort_relocs_p): Declare.
* elf32-mips.c (elf_backend_sort_relocs_p): Define.
* elf64-mips.c (elf_backend_sort_relocs_p): Define.
PR binutils/17512
* objdump.c (display_any_bfd): Avoid infinite loop closing and
opening the same archive again and again.
* archive64.c (bfd_elf64_archive_slurp_armap): Add range checks.
* libbfd.c (safe_read_leb128): New function.
* libbfd-in.h (safe_read_leb128): Add prototype.
* libbfd.h: Regenerate.
* elf-attrs.c (_bfd_elf_parse_attributes): Use safe_read_leb128.
Check for an over-long subsection length.
* elf.c (elf_parse_notes): Check that the namedata is long enough
for the string comparison that is about to be performed.
(elf_read_notes): Zero-terminate the note buffer.
Now that ld -r relocs are sorted by the pr17666 fix, there isn't so
much need to sort incoming relocs.
* elf64-ppc.c (sort_r_offset): Delete.
(ppc64_elf_edit_opd): Don't sort input relocs.
PR binutils/17531
* dwarf.c (display_debug_frames): Check for a negative
augmentation data length.
(display_gdb_index): Check for invalid offsets.
* elfcomm.c (process_archive_index_and_symbols): Check for an
index number that overflows when multiplied by the ar index size.
* readelf.c (dump_ia64_unwind): Add range checks.
(slurp_ia64_unwind_table): Change to a boolean function. Add
range checks.
(process_version_sections): Add range checks.
(get_symbol_version_string): Add check for missing section
headers.
That's right, block_lookup_symbol_primary()'s additional requirement over
block_lookup_symbol() is:
Function is useful if one iterates all global/static blocks of an
objfile.
Which is satisfied both in lookup_symbol_in_objfile_symtabs() and in
lookup_global_symbol_from_objfile() thanks to their's ALL_OBJFILE_COMPUNITS.
In fact after reverting that ba715d7fe4 above
the lines of code were exactly the same.
So instead of accelerating both lookup_symbol_in_objfile_symtabs() and
lookup_global_symbol_from_objfile() I just accelerated
lookup_symbol_in_objfile_symtabs() and I am proposing to reuse
lookup_symbol_in_objfile_symtabs() in lookup_global_symbol_from_objfile()
instead. In fact such unification would already save some lines of code even
before the checked-in acceleration patch above.
gdb/ChangeLog
2014-12-05 Jan Kratochvil <jan.kratochvil@redhat.com>
* symtab.c (lookup_symbol_in_objfile_symtabs): New declaration.
(lookup_global_symbol_from_objfile): Call it.
I am just not sure if we should go the route of
struct objfile * -> const struct objfile *
or the other way of:
const struct objfile * -> struct objfile *
Normally const adding is better but here I do not see much useful to have any
struct objfile * const and then it just causes pointer compatibility problems.
On Wed, 03 Dec 2014 18:18:44 +0100, Doug Evans wrote:
struct objfile is one case where I've decided to just leave the const
out and not worry about it.
gdb/ChangeLog
2014-12-05 Jan Kratochvil <jan.kratochvil@redhat.com>
Remove const from struct objfile *.
* solib-darwin.c, solib-spu.c, solib-svr4.c, solib.c, solist.h,
symtab.c, symtab.h: In these files.
This patch is to revert my previous commit, because we shouldn't remove
gdbtk bits from gdb/testsuite/configure.ac while keep gdbtk bits in
gdb/configure.ac.
gdb/testsuite:
2014-12-05 Yao Qi <yao@codesourcery.com>
Revert:
* configure.ac: Remove AC_ARG_ENABLE for gdbtk. Don't invoke
AC_CONFIG_SUBDIRS(gdb.gdbtk).
* configure: Re-generated.
Some gdb.guile tests such as scm-error.exp copies .scm file to
${subdir}/, how ${subdir} doesn't exist in parallel testing
(outputs/${subdir} exists).
$ make -j3 check TESTS='gdb.guile/scm-section-script.exp gdb.guile/scm-error.exp gdb.guile/scm-frame-args.exp'
ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-section-script.scm to gdb.guile/t-scm-section-script.scm: cp: cannot create regular file 'gdb.guile/t-scm-section-script.scm': No such file or directory
ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-frame-args.scm to gdb.guile/t-scm-frame-args.scm: cp: cannot create regular file
'gdb.guile/t-scm-frame-args.scm': No such file or directory
ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-error-1.scm to gdb.guile/t-scm-error-1.scm: cp: cannot create regular file 'gdb.guile/t-scm-error-1.scm': No such file or directory
This patch is to remove the third argument of gdb_remote_download, so
that gdb_remote_download can return the correct location.
Further, these tests only copy .scm files to a different name. From what
I can tell from the comments, looks we do this to avoid clobbering file
in in-tree build. However, if source and dest of copy are the same, the
operation is no-op. So it makes few sense to copy .scm files to a
different names. I tried in-tree build/test with this patch, test
result isn't changed.
gdb/testsuite:
2014-12-05 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-error.exp: Remove the third argument to
gdb_remote_download.
* gdb.guile/scm-frame-args.exp: Likewise.
* gdb.guile/scm-section-script.exp: Likewise.
This patch causes regressions in ada's operator_bp.exp test.
That's because it uses wild_match which expects arguments in
the original order.
There is still a bug here. It's hard to see because either minsyms
save the day, or the needed symtab gets expanded before linespecs
need it because of the call to cp_canonicalize_string_no_typedefs
in linespec.c:find_linespec_symbols.
But if you disable both of those things, then the bug is visible.
bash$ ./gdb -D ./data-directory testsuite/gdb.cp/anon-ns
(gdb) b doit(void)
Function "doit(void)" not defined.
gdb/ChangeLog:
Revert:
PR symtab/17602
* linespec.c (iterate_name_matcher): Fix arguments to symbol_name_cmp.
This patch is to use standard_testfile in i386-bp_permanent.exp to replace
existing setting to testfile, srcfile and binfile. So it fixes a problem
in i386-bp_permanent.exp in parallel testing.
$ make -j3 check TESTS='gdb.guile/scm-section-script.exp gdb.arch/i386-bp_permanent.exp'
....
gdb compile failed, /usr/bin/ld: cannot open output file x86/gdb/testsuite/gdb.arch/i386-bp_permanent: No such file or directory
collect2: error: ld returned 1 exit status
gdb/testsuite:
2014-12-05 Yao Qi <yao@codesourcery.com>
* gdb.arch/i386-bp_permanent.exp: Use standard_testfile.
In i386 and x86-64 binaries with ifunc, relocations against .got.plt
section may not be in the same order as entries in PLT section. This
patch adds _bfd_elf_ifunc_get_synthetic_symtab. It takes a function
pointer which returns an array of PLT entry symbol values. It calls
the function pointer to get the PLT entry symbol value array indexed
by relocation index, instead of calling plt_sym_val on each relocation
index.
PR binutils/17677
* elf-bfd.h (_bfd_elf_ifunc_get_synthetic_symtab): New prototype.
* elf-ifunc.c (_bfd_elf_ifunc_get_synthetic_symtab): New
function.
* elf32-i386.c (elf_i386_plt_sym_val): Removed.
(elf_backend_plt_sym_val): Likewise.
(elf_i386_get_plt_sym_val): New.
(elf_i386_get_synthetic_symtab): Likewise.
(bfd_elf32_get_synthetic_symtab): Likewise.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Removed.
(elf_x86_64_plt_sym_val_offset_plt_bnd): Likewise.
(elf_backend_plt_sym_val): Likewise.
(elf_x86_64_get_plt_sym_val): New.
(elf_x86_64_get_synthetic_symtab): Use
_bfd_elf_ifunc_get_synthetic_symtab.
(bfd_elf64_get_synthetic_symtab): Don't undefine for NaCl.
Mixing 64-bit and 32-bit types led to the wrong promotions. Keep
calculation in same type. Also fix a case where PLTREL25 reloc addend
should be ignored.
* Powerpc.cc (Target_powerpc::Branch_info::make_stub): Ignore
addend of PLTREL24 reloc when not generating a plt stub. Make
max_branch_offset an "Address".
(Stub_table::can_read_stub): Make max_branch_offset an "Address".
(Target_powerpc::Relocate::relocate): Likewise.
During debugging I get 10-30 seconds for a response to simple commands like:
(gdb) print vectorvar.size()
With this patch the performance gets to 1-2 seconds which is somehow
acceptable. The problem is that dwarf2_gdb_index_functions.lookup_symbol
(quick_symbol_functions::lookup_symbol) may return (and returns) NULL even for
symbols which are present in .gdb_index but which can be found in already
expanded symtab. But searching in the already expanded symtabs is just too
slow when there are 400000+ expanded symtabs. There would be needed some
single global hash table for each objfile so that one does not have to iterate
all symtabs. Which .gdb_index could perfectly serve for, just its
lookup_symbol() would need to return authoritative yes/no answers.
Even after such fix these two simple patches are useful for example for
non-.gdb_index files.
One can reproduce the slugging interactive GDB performance with:
#include <string>
using namespace std;
string var;
class C {
public:
void m() {}
};
int main() {
C c;
c.m();
return 0;
}
g++ -o slow slow.C -Wall -g $(pkg-config --libs gtkmm-3.0)
gdb ./slow -ex 'b C::m' -ex 'maintenance set per-command space' -ex 'maintenance set per-command symtab' -ex 'maintenance set per-command
time' -ex r
[...]
(gdb) p <tab><tab>
Display all 183904 possibilities? (y or n) n
(gdb) p/r var
$1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No
data fields>}, _M_p = 0x3a4db073d8 <std::string::_Rep::_S_empty_rep_storage+24> ""}}
Command execution time: 20.023000 (cpu), 20.118665 (wall)
^^^^^^^^^
Space used: 927997952 (+0 for this command)
Without DWZ there are X global blocks for X primary symtabs for X CUs of
objfile. With DWZ there are X+Y global blocks for X+Y primary symtabs for
X+Y CUs where Y are 'DW_TAG_partial_unit's.
For 'DW_TAG_partial_unit's (Ys) their blockvector is usually empty. But not
always, I have found there typedef symbols, there can IMO be optimized-out
static variables etc.
Neither of the patches should cause any visible behavior change.
gdb/ChangeLog
2014-12-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* block.c (block_lookup_symbol_primary): New function.
* block.h (block_lookup_symbol_primary): New declaration.
* symtab.c (lookup_symbol_in_objfile_symtabs): Assert BLOCK_INDEX.
Call block_lookup_symbol_primary.
