Commit Graph

94207 Commits

Author SHA1 Message Date
Nick Clifton
8e4bd9922a Updated Spanish translation for the gas sub-directory. 2018-05-01 16:42:41 +01:00
Nick Clifton
b5778783ad Bring in support for the NFP target in the config.sub file.
* config.guess: Synchronize with config project master sources.
	* config.sub: Likewise.
2018-05-01 16:35:04 +01:00
Francois H. Theron
1063beb58c Add the Netronome Flow Processor as a build target to the top-level configure.ac file.
* configure.ac: Added "nfp" target.
	* configure: Regenerate.
2018-05-01 16:23:21 +01:00
Dan Robertson
1632f8baf0 rust: Fix null deref when casting (PR 23124)
Fix a null dereference when casting a value to a unit type.

ChangeLog
2018-04-28  Dan Robertson  <danlrobertson89@gmail.com>

	PR rust/23124
	* gdb/rust-exp.y (convert_params_to_types): Ensure that the params
	pointer is not null before dereferencing it.

testsuite/ChangeLog
2018-04-28  Dan Robertson  <danlrobertson89@gmail.com>

	PR rust/23124
	* gdb.rust/expr.exp: Test that the unit type is correctly parsed
	when casting.
2018-04-30 23:02:01 -06:00
GDB Administrator
e31efe5645 Automatic date update in version.in 2018-05-01 00:00:37 +00:00
Joel Brobecker
0ca1fc2913 [Ada/ravenscar] error during "continue" after task/thread switch
When debugging a program using the Ada ravenscar profile, resuming
a program's execution after having switched to a different task
sometimes yields the following error:

     (gdb) cont
     Continuing.
     Cannot execute this command while the target is running.
     Use the "interrupt" command to stop the target
     and then try again.

In short, the Ravenscar profile is a standardized subset of Ada which
allows tasking (often mapped to threads). We often use it on baremetal
targets where there is no OS support. Thread support is implemented
as a thread target_ops layer. It sits on top of the "remote" layer,
so we can do thread debugging against baremetal targets to which GDB
is connected via "target remote".

What happens, when the user request the program to resume execution,
is the following:

  - the ravenscar-thread target_ops layer gets the order to resume
    the program's execution. The current thread is not the active
    thread in the inferior, and the "remote" layer doesn't know
    about that thread anyway. So what we do is (see ravenscar_resume):

       + switch inferior_ptid to the ptid of the actually active thread;
       + ask the layer beneath us to actually do the resume.

  - Once that's done, the resuming itself is done. But execute_command
    (in top.c) actually does a bit more. More precisely, it unconditionally
    checks to see if the language may no longer be matching the current
    frame:

        check_frame_language_change ();

The problem, here, is that we haven't received the "stop" event
from the inferior, yet. This part will be handled by the event loop,
which is done later. So, checking for the language-change here
doesn't make sense, since we don't really have a frame. In our
case, the error comes from the fact that we end up trying to read
the registers, which causes the error while the remote protocol
is waiting for the event showing the inferior stopped.

This apparently used to work, but it is believed that this was only
accidental. In other words, we had enough information already cached
within GDB that we were able to perform the entire call to
check_frame_language_change without actually querying the target.
On PowerPC targets, this started to fail as a side-effect of a minor
change in the way we get to the regcache during the handling of
software-single-step (which seems fine).

This patch fixes the issue by only calling check_frame_language_change
in cases the inferior isn't running. Otherwise, it skips it, knowing
that the event loop should eventually get to it.

gdb/ChangeLog:

        * top.c (execute_command): Do not call check_frame_language_change
        if the inferior is running.

Tested on x86_64-linux, no regression. Also tested on aarch64-elf,
arm-elf, leon3-elf, and ppc-elf, but using AdaCore's testsuite.
2018-04-30 18:13:23 -04:00
Tom Tromey
7676193654 Remove a use of is_mi_like_p from darwin-nat-info.c
This removes a use of is_mi_like_p from darwin-nat-info.c.
This is not needed because MI already ignores ui_out::text.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* darwin-nat-info.c (darwin_debug_regions_recurse): Remove use of
	is_mi_like_p.
2018-04-30 12:59:06 -06:00
Tom Tromey
2d33446d4d Remove some is_mi_like_p from breakpoint code
This removes some uses of is_mi_like_p from the breakpoint code.  The
break-catch-throw.c change brings it into line with what other
breakpoint classes do.  The other changes simply replace printf calls
with ui_out::text or ui_out::message calls.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* breakpoint.c (mention): Remove use of is_mi_like_p.
	(print_mention_ranged_breakpoint): Likewise.
	* break-catch-throw.c (print_it_exception_catchpoint): Remove use
	of is_mi_like_p.
2018-04-30 12:59:05 -06:00
Tom Tromey
f3c6ababac Remove a use of is_mi_like_p from tracepoint.c
This removes a use of is_mi_like_p and changes a printf_filtered into
a call to ui_out::text.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* tracepoint.c (tvariables_info_1): Remove use of is_mi_like_p.
2018-04-30 12:59:05 -06:00
Tom Tromey
40c03530b1 Remove some uses of is_mi_like_p from spu-tdep.c
There were a few spots in spu-tdep.c where a use of is_mi_like_p was
not needed.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* spu-tdep.c (info_spu_mailbox_list, info_spu_dma_cmdlist)
	(info_spu_event_command): Remove some uses of is_mi_like_p.
2018-04-30 12:59:04 -06:00
Tom Tromey
2038b7fdf3 Remove some uses of is_mi_like_p from py-framefilter.c
Some uses of is_mi_like_p in py-framefilter.c were not needed.  In
general a call to ui_out::text, ui_out::message, or ui_out::spaces
does not need to be guarded -- these are already ignored by MI.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* python/py-framefilter.c (py_print_single_arg)
	(enumerate_locals, py_print_args, py_print_frame): Remove some
	uses of is_mi_like_p.
2018-04-30 12:59:04 -06:00
Tom Tromey
4904c3c6b6 Make do_is_mi_like_p const.
This changes ui_out to make is_mi_like_p and do_is_mi_like_p "const".

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* ui-out.c: Update.
	* cli-out.h (cli_ui_out::do_is_mi_like_p): Update.
	* ui-out.h (ui_out::is_mi_like_p): Now const.
	(ui_out::do_is_mi_like_p): Now const.
	* mi/mi-out.h (mi_ui_out::do_is_mi_like_p): Update.
2018-04-30 12:59:03 -06:00
Tom Tromey
7c66fffc1f Change Python code to use new_reference
This changes a few spots in the Python code to use new_reference
rather than the manual incref+constructor that was previously being
done.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* varobj.c (varobj_set_visualizer): Use new_reference.
	* python/python.c (gdbpy_decode_line): Use new_reference.
	* python/py-cmd.c (cmdpy_function, cmdpy_completer_helper): Use
	new_reference.
2018-04-30 11:33:12 -06:00
Tom Tromey
bbfa6f0086 Use new_reference for struct value
value_incref returned its argument just as a convenience, which in the
end turned out to only be used in precisely the cases where
new_reference helps.  So, this patch changes value_incref to return
void and changes some value-using code to use new_reference.

I also noticed that the comments for value_incref and value_decref
were swapped, so this patch fixes those.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* varobj.c (install_new_value): Use new_reference.
	* value.h (value_incref): Return void.  Swap intro comment with
	value_decref.
	* value.c (set_value_parent): Use new_reference.
	(value_incref): Return void.  Update intro comment.
	(release_value): Use new_reference.
	* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Use new_reference.
2018-04-30 11:33:11 -06:00
Tom Tromey
1831a9f9d3 Remove new_bfd_ref
For gdb_bfd_ref_ptr, gdb already had a convenience function like the
new gdb_ref_ptr::new_reference -- called new_bfd_ref.  This patch
removes it in favor of the new common function.

While doing this I also noticed that the comment for gdb_bfd_open was
incorrect (in a way related to reference counting), so this patch
updates the comment as well.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* symfile-mem.c (symbol_file_add_from_memory): Use new_reference.
	* gdb_bfd.h (new_bfd_ref): Remove.
	(gdb_bfd_open): Update comment.
	* gdb_bfd.c (gdb_bfd_open, gdb_bfd_fopen, gdb_bfd_openr)
	(gdb_bfd_openw, gdb_bfd_openr_iovec, gdb_bfd_record_inclusion)
	(gdb_bfd_fdopenr): Use new_reference.
	* exec.c (exec_file_attach): Use new_reference.
2018-04-30 11:33:11 -06:00
Tom Tromey
7c1b5f3db7 Introduce ref_ptr::new_reference
I noticed a common pattern with gdb::ref_ptr, where callers would
"incref" and then create a new wrapper object, like:

    Py_INCREF (obj);
    gdbpy_ref<> ref (obj);

The ref_ptr constructor intentionally does not acquire a new
reference, but it seemed to me that it would be reasonable to add a
static member function that does so.

In this patch I chose to call the function "new_reference".  I
considered "acquire_reference" as well, but "new" seemed less
ambiguous than "acquire" to me.

ChangeLog
2018-04-30  Tom Tromey  <tom@tromey.com>

	* common/gdb_ref_ptr.h (ref_ptr::new_reference): New static
	method.
2018-04-30 11:33:11 -06:00
Tom Tromey
e11fb955fb Remove long_long_align_bit gdbarch attribute
This removes the long_long_align_bit gdbarch attribute in favor of
type_align.  This uncovered two possible issues.

First, arc-tdep.c claimed that long long alignment was 32 bits, but as
discussed on the list, ARC has a maximum alignment of 32 bits, so I've
added an arc_type_align function to account for this.

Second, jit.c, the sole user of long_long_align_bit, was confusing
"long long" with uint64_t.  The relevant structure is defined in the
JIT API part of the manual as:

     struct jit_code_entry
     {
       struct jit_code_entry *next_entry;
       struct jit_code_entry *prev_entry;
       const char *symfile_addr;
       uint64_t symfile_size;
     };

I've changed this code to use uint64_t.

2018-04-30  Tom Tromey  <tom@tromey.com>

	* jit.c (jit_read_code_entry): Use type_align.
	* i386-tdep.c (i386_gdbarch_init): Don't call
	set_gdbarch_long_long_align_bit.
	* gdbarch.sh: Remove long_long_align_bit.
	* gdbarch.c, gdbarch.h: Rebuild.
	* arc-tdep.c (arc_type_align): New function.
	(arc_gdbarch_init): Use arc_type_align.  Don't call
	set_gdbarch_long_long_align_bit.
2018-04-30 11:25:32 -06:00
Tom Tromey
2fff16dd8c Remove rust_type_alignment
rust_type_alignment is not needed now that gdb has type alignment
code.  So, this removes it.

2018-04-30  Tom Tromey  <tom@tromey.com>

	* rust-lang.c (rust_type_alignment): Remove.
	(rust_composite_type): Use type_align.
2018-04-30 11:25:32 -06:00
Tom Tromey
6d7bb8246b Expose type alignment on gdb.Type
This adds an "alignof" attribute to gdb.Type in the Python API.

2018-04-30  Tom Tromey  <tom@tromey.com>

	* NEWS: Mention Type.align.
	* python/py-type.c (typy_get_alignof): New function.
	(type_object_getset): Add "alignof".

2018-04-30  Tom Tromey  <tom@tromey.com>

	* python.texi (Types In Python): Document Type.align.

2018-04-30  Tom Tromey  <tom@tromey.com>

	* gdb.python/py-type.exp: Check align attribute.
	* gdb.python/py-type.c: New "aligncheck" global.
2018-04-30 11:25:31 -06:00
Tom Tromey
007e153034 Handle alignof and _Alignof
This adds alignof and _Alignof to the C/C++ expression parser, and
adds new tests to test the features.  The tests are written to try to
ensure that gdb's knowledge of alignment rules stays in sync with the
compiler's.

2018-04-30  Tom Tromey  <tom@tromey.com>

	PR exp/17095:
	* NEWS: Update.
	* std-operator.def (UNOP_ALIGNOF): New operator.
	* expprint.c (dump_subexp_body_standard) <case UNOP_ALIGNOF>:
	New.
	* eval.c (evaluate_subexp_standard) <case UNOP_ALIGNOF>: New.
	* c-lang.c (c_op_print_tab): Add alignof.
	* c-exp.y (ALIGNOF): New token.
	(exp): Add "ALIGNOF" production.
	(ident_tokens): Add _Alignof and alignof.

2018-04-30  Tom Tromey  <tom@tromey.com>

	PR exp/17095:
	* gdb.dwarf2/dw2-align.exp: New file.
	* gdb.cp/align.exp: New file.
	* gdb.base/align.exp: New file.
	* lib/gdb.exp (gdb_int128_helper): New proc.
	(has_int128_c, has_int128_cxx): New caching procs.
2018-04-30 11:25:31 -06:00
Tom Tromey
2b4424c35b Add initial type alignment support
This adds some basic type alignment support to gdb.  It changes struct
type to store the alignment, and updates dwarf2read.c to handle
DW_AT_alignment.  It also adds a new gdbarch method and updates
i386-tdep.c.

None of this new functionality is used anywhere yet, so tests will
wait until the next patch.

2018-04-30  Tom Tromey  <tom@tromey.com>

	* i386-tdep.c (i386_type_align): New function.
	(i386_gdbarch_init): Update.
	* gdbarch.sh (type_align): New method.
	* gdbarch.c, gdbarch.h: Rebuild.
	* arch-utils.h (default_type_align): Declare.
	* arch-utils.c (default_type_align): New function.
	* gdbtypes.h (TYPE_ALIGN_BITS): New define.
	(struct type) <align_log2>: New field.
	<instance_flags>: Now a bitfield.
	(TYPE_RAW_ALIGN): New macro.
	(type_align, type_raw_align, set_type_align): Declare.
	* gdbtypes.c (type_align, type_raw_align, set_type_align): New
	functions.
	* dwarf2read.c (quirk_rust_enum): Set type alignment.
	(get_alignment, maybe_set_alignment): New functions.
	(read_structure_type, read_enumeration_type, read_array_type)
	(read_set_type, read_tag_pointer_type, read_tag_reference_type)
	(read_subrange_type, read_base_type): Set type alignment.
2018-04-30 11:25:30 -06:00
Francois H. Theron
fe944acf8f This patch adds support to objdump for disassembly of NFP (Netronome Flow Processor) ELF files (.nffw) as well as some basic readelf support.
bfd	* Makefile.am: Added NFP files to build.
	* archures.c: Added bfd_arch_nfp
	* config.bfd: Added NFP support.
	* configure.ac: Added NFP support.
	* cpu-nfp.c: New, for NFP support.
	* elf-bfd.h: Added elf_section_info()
	* elf64-nfp.c: New, for NFP support.
	* po/SRC-POTFILES.in: Added NFP source files.
	* targets.c: Added nfp_elf64_vec
	* bfd-in2.h: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

binutils* readelf.c: Very basic support for EM_NFP and its section types.
	* testsuite/binutils-all/nfp: New directory.
	* testsuite/binutils-all/nfp/objdump.exp: New file.  Run new
	tests.
	* testsuite/binutils-all/nfp/test2_ctx8.d: New file.
	* testsuite/binutils-all/nfp/test2_no-pc_ctx4.d: New file.
	* testsuite/binutils-all/nfp/test1.d: New file.
	* testsuite/binutils-all/nfp/nfp6000.nffw: New file.
	* testsuite/binutils-all/nfp/test2_nfp6000.nffw: New file.
	* NEWS: Mention the new support.

include	* dis-asm.h: Added print_nfp_disassembler_options prototype.
	* elf/common.h: Added EM_NFP, officially assigned. See Google Group
	Generic System V Application Binary Interface.
	* elf/nfp.h: New, for NFP support.
	* opcode/nfp.h: New, for NFP support.

opcodes	Makefile.am: Added nfp-dis.c.
	configure.ac: Added bfd_nfp_arch.
	disassemble.h: Added print_insn_nfp prototype.
	disassemble.c: Added ARCH_nfp and call to print_insn_nfp
	nfp-dis.c: New, for NFP support.
	po/POTFILES.in: Added nfp-dis.c to the list.
	Makefile.in: Regenerate.
	configure: Regenerate.
2018-04-30 17:02:59 +01:00
Simon Marchi
d33bc52e51 Use bool in read_index_from_section
gdb/ChangeLog:

	* dwarf2read.c (read_index_from_section): Use bool.
2018-04-30 11:06:57 -04:00
GDB Administrator
425050ff8d Automatic date update in version.in 2018-04-30 00:00:32 +00:00
Fabian Groffen
e28b63a989 proc-events.c: fix compilation on Solaris
This patch adds a guard around the usage of SYS_uuidsys, which is
not available on (at least) Solaris 10 and OpenIndiana.

gdb/ChangeLog:

	PR gdb/22950
	* proc-events.c (init_syscall_table): Guard usage os SYS_uuidsys
	with #ifdef.
2018-04-29 12:05:10 -04:00
John Reiser
cd8c76e410 Fix race when building ada-lex.c
Prevent a race when building ada-lex.c, and any target of rules .c:.l or
.c:.y.  The target should be written only at the last step, else SIGINT
(^C) can leave an inconsistent state.  Being .PRECIOUS makes it even
worse.

gdb/ChangeLog:

	PR build/22873
	* gdb/Makefile.in: (.c:.l, .c:.y): Write the target only in the
	last step, and do it atomically.
2018-04-29 11:57:38 -04:00
GDB Administrator
1c831f5654 Automatic date update in version.in 2018-04-29 00:01:17 +00:00
GDB Administrator
0d40a647f2 Automatic date update in version.in 2018-04-28 00:00:28 +00:00
Alexandre Oliva
476d250ee8 Add libcc1 v1 compatibility to C compile feature
This patch adds v1 compatibiltiy to the C compile feature.  The only change
in v1 concerns the handling of integer types, which permits GDB to specify
the built-in name for the type.

As far as I know, the C frontend is still on v0, so this patch is purely
precautionary. [By default C++ compile uses the equivalent of the C
frontend's int_type and float_type (aka the "v1" versions).]

gdb/ChangeLog:

	* compile/compile-c-types.c (convert_int, convert_float):
	Update for C FE v1.
2018-04-27 12:36:19 -07:00
Tom Tromey
6873858b7e Add inclusive range support for Rust
This is version 2 of the patch to add inclusive range support for
Rust.  I believe it addresses all review comments.

Rust recently stabilized the inclusive range feature:

    https://github.com/rust-lang/rust/issues/28237

An inclusive range is an expression like "..= EXPR" or "EXPR ..=
EXPR".  It is like an ordinary range, except the upper bound is
inclusive, not exclusive.

This patch adds support for this feature to gdb.

Regression tested on x86-64 Fedora 27.

2018-04-27  Tom Tromey  <tom@tromey.com>

	PR rust/22545:
	* rust-lang.c (rust_inclusive_range_type_p): New function.
	(rust_range): Handle inclusive ranges.
	(rust_compute_range): Likewise.
	* rust-exp.y (struct rust_op) <inclusive>: New field.
	(DOTDOTEQ): New constant.
	(range_expr): Add "..=" productions.
	(operator_tokens): Add "..=" token.
	(ast_range): Add "inclusive" parameter.
	(convert_ast_to_expression) <case OP_RANGE>: Handle inclusive
	ranges.
	* parse.c (operator_length_standard) <case OP_RANGE>: Handle new
	bounds values.
	* expression.h (enum range_type) <NONE_BOUND_DEFAULT_EXCLUSIVE,
	LOW_BOUND_DEFAULT_EXCLUSIVE>: New constants.
	Update comments.
	* expprint.c (print_subexp_standard): Handle new bounds values.
	(dump_subexp_body_standard): Likewise.

2018-04-27  Tom Tromey  <tom@tromey.com>

	PR rust/22545:
	* gdb.rust/simple.exp: Add inclusive range tests.
2018-04-27 13:20:13 -06:00
Tom Tromey
632e107b32 Enable -Wsuggest-override
I noticed the existence of -Wsuggest-override and so this patch
enables it for gdb.  It found a few spots that could use "override".
Also I went ahead and removed all uses of the "OVERRIDE" macro.

Using override is beneficial because it makes it harder to change a
base class and then forget to change a derived class.

Tested by the buildbot.

ChangeLog
2018-04-27  Tom Tromey  <tom@tromey.com>

	* configure: Rebuild.
	* warning.m4 (AM_GDB_WARNINGS): Add -Wsuggest-override.
	* dwarf2loc.c (class dwarf_evaluate_loc_desc): Use "override", not
	"OVERRIDE".
	(class symbol_needs_eval_context): Likewise.
	* dwarf2read.c (mock_mapped_index::symbol_name_count)
	(mock_mapped_index::symbol_name_at): Use "override".  Remove
	"virtual".
	* dwarf2-frame.c (dwarf_expr_executor::get_addr_index): Use
	"override".
	(class dwarf_expr_executor): Use "override", not "OVERRIDE".
	* aarch64-tdep.c (instruction_reader::read): Use "override".
	(instruction_reader_test::read): Likewise.
	* arm-tdep.c (instruction_reader::read): Use "override".
	(instruction_reader_thumb::read): Likewise.

gdbserver/ChangeLog
2018-04-27  Tom Tromey  <tom@tromey.com>

	* configure: Rebuild.
2018-04-27 12:53:14 -06:00
Maciej W. Rozycki
197b262f98 MIPS/LD/testsuite: Update `run_dump_test' cases for non-DSO targets
Mark these `run_dump_test' cases across `ld-mips-elf/mips-elf.exp' that
are run unconditionally and require shared library support for exclusion
for targets that do not have such support, removing these failures:

FAIL: MIPS BAL/JALX in PIC mode
FAIL: microMIPS BAL/JALX in PIC mode
FAIL: MIPS BAL/JALX in PIC mode (ignore branch ISA)
FAIL: microMIPS BAL/JALX in PIC mode (ignore branch ISA)
FAIL: ld-mips-elf/hash1a
FAIL: ld-mips-elf/hash1b
FAIL: ld-mips-elf/hash1c

with `mipsel-ps2-elf' and `mips64el-ps2-elf' targets.  Tests that are
guarded with `linux_gnu' will have to be reviewed separately.

	ld/
	* testsuite/ld-mips-elf/bal-jalx-pic.d: Only run for
	`check_shared_lib_support' targets.
	* testsuite/ld-mips-elf/bal-jalx-pic-n32.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-n64.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-micromips.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-micromips-n32.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-micromips-n64.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore-n32.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore-n64.d: Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore-micromips.d:
	Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore-micromips-n32.d:
	Likewise.
	* testsuite/ld-mips-elf/bal-jalx-pic-ignore-micromips-n64.d:
	Likewise.
	* testsuite/ld-mips-elf/hash1a.d: Likewise.
	* testsuite/ld-mips-elf/hash1b.d: Likewise.
	* testsuite/ld-mips-elf/hash1c.d: Likewise.
	* testsuite/ld-mips-elf/relax-jalr-n32-shared.d: Likewise.
	* testsuite/ld-mips-elf/relax-jalr-n64-shared.d: Likewise.
2018-04-27 15:25:20 +01:00
Maciej W. Rozycki
6d9dabbbc6 testsuite: Support filtering targets by TCL procedure in `run_dump_test'
Implement a more complex way of selecting targets to include or exclude
with `run_dump_test' cases, by extending the syntax for the `target',
`not-target', `skip' and `not-skip' options (with the binutils and GAS
test suites) and the `target', `alltargets' and `notarget' options (with
the LD test suite) to also accept a name of a TCL procedure instead of a
target triplet glob matching expression.  The result, 1 or 0, of the
procedure determines whether the test is to be run or not.  This mimics
and expands `dg-require-effective-target' from the GCC test suite.

Names of TCL procedures are supplied in square brackets `[]' as with TCL
procedure calls, observing that target triplet glob matching expressions
do not normally start and end with matching square brackets both at a
time.  Arguments for procedures are allowed if required.

Having a way to specify a complex condition for a `run_dump_test' case
to run has the advantage of keeping it local within the test case itself
where tool options related to the check might be also present, removing
the need to wrap `run_dump_test' calls into an `if' block whose only
reason is to do a feature check, and ultimately lets one have the test
reported as UNSUPPORTED automagically if required (not currently
supported by the `run_dump_test' options used for LD).

	binutils/
	* testsuite/lib/binutils-common.exp (match_target): New procedure.
	* testsuite/lib/utils-lib.exp (run_dump_test): Use it in place
	of `istarget' for matching with `target', `not-target', `skip'
	and `not-skip' options.

	gas/
	* testsuite/lib/gas-defs.exp (run_dump_test): Use `match_target'
	in place of `istarget' for matching with `target', `not-target',
	`skip' and `not-skip' options.

	ld/
	* testsuite/lib/ld-lib.exp (run_dump_test): Use `match_target'
	in place of `istarget' for matching with `target', `alltargets'
	and `notarget' options.
2018-04-27 15:25:20 +01:00
Igor Tsimbalist
aa17843739 Revert "Enable Intel MOVDIRI, MOVDIR64B instructions."
This reverts commit a914a7c958.
2018-04-27 14:34:13 +02:00
Alan Modra
ffa389a396 Regenerate some files for recent ARM patches
bfd/
	* bfd-in2.h: Regenerate.
	* libbfd.h: Regenerate.
ld/
	* po/BLD-POTFILES.in: Regenerate.
2018-04-27 19:27:33 +09:30
Alan Modra
04383fd15b PR23123, PowerPC32 ifunc regression
Two of the gcc ifunc tests fail for ppc32, due to my pr22374 fix being
a little too enthusiastic in trimming PLT entries.  ppc64 doesn't have
the same failures because ppc64_elf_check_relocs happens to set
needs_plt for any ifunc reloc.

	PR 23123
	PR 22374
	* elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Don't drop plt
	relocs for ifuncs.
	* elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Comment fixes.
2018-04-27 17:12:32 +09:30
GDB Administrator
ced8ce28a4 Automatic date update in version.in 2018-04-27 00:00:36 +00:00
Andrzej Kaczmarek
b75abf5bb6 Fix remote 'g' command error handling (PR remote/9665)
'g' command returns hex-string as response so simply checking for 'E'
to determine if it failed is not enough and can trigger spurious error
messages.  For example, invalid behaviour can be easily triggered on
Cortex-M as follows:

  (gdb) set $r0 = 0xe0
  Sending packet: $P0=e0000000#72...Packet received: OK
  Packet P (set-register) is supported
  Sending packet: $g#67...Packet received: E0000000849A0020...
  Remote failure reply: E0000000849A0020...

This patch fixes the problem by calling putpkt()/getpkt() directly and
checking result with packet_check_result().  This works fine since Enn
response has odd number of bytes while proper response has even number
of bytes.

Also, remote_send() is now not used anywhere so it can be removed.

gdb/Changelog:
2018-04-26  Andrzej Kaczmarek  <andrzej.kaczmarek@codecoup.pl>

	PR remote/9665
	* remote.c (send_g_packet): Use putpkt/getpkt/packet_check_result
	instead of remote_send.
	(remote_send): Remove.
2018-04-26 23:47:25 +01:00
Igor Tsimbalist
a914a7c958 Enable Intel MOVDIRI, MOVDIR64B instructions.
gas/
	* config/tc-i386.c (cpu_arch): Add .movdir, .movdir64b.
	(cpu_noarch): Likewise.
	(process_suffix): Add check for register size.
	* doc/c-i386.texi: Document movdiri, movdir64b.
	* testsuite/gas/i386/i386.exp: Run MOVDIR{I,64B} tests.
	* testsuite/gas/i386/movdir-intel.d: New test.
	* testsuite/gas/i386/movdir.d: Likewise.
	* testsuite/gas/i386/movdir.s: Likewise.
	* testsuite/gas/i386/movdir64b-reg.s: Likewise.
	* testsuite/gas/i386/movdir64b-reg.l: Likewise.
	* testsuite/gas/i386/x86-64-movdir-intel.d: Likewise.
	* testsuite/gas/i386/x86-64-movdir.d: Likewise.
	* testsuite/gas/i386/x86-64-movdir.s: Likewise.
	* testsuite/gas/i386/x86-64-movdir64b-reg.s: Likewise.
	* testsuite/gas/i386/x86-64-movdir64b-reg.l: Likewise.

opcodes/
	* i386-dis.c (enum): Add PREFIX_0F38F8, PREFIX_0F38F9.
	(prefix_table): New instructions (see prefix above).
	Add Gva macro and handling in OP_G.
	* i386-gen.c (cpu_flag_init): Add CPU_MOVDIRI_FLAGS,
	CPU_MOVDIR64B_FLAGS.
	(cpu_flags): Likewise.
	(opcode_modifiers): Add AddrPrefixOpReg.
	(i386_opcode_modifier): Likewise.
	* i386-opc.h (enum): Add CpuMOVDIRI, CpuMOVDIR64B.
	(i386_cpu_flags): Likewise.
	* i386-opc.tbl: Add movidir{i,64b}.
	* i386-init.h: Regenerate.
	* i386-tbl.h: Likewise.
2018-04-26 23:34:04 +02:00
Nick Clifton
0df8ad28f0 Extend the assembler so that it can automatically generate GNU Build attribute notes if none are present in the input files.
gas	* as.c (flag_generate_build_notes): New variable.
	(show_usage): Add entry for --generate-missing-build-notes.
	(parse_args): Parse --generate-missing-build-notes.
	* as.h: Export flag_generate_build_notes.
	* symbols.c (save_symbol_name): Ensure that the name parameter is
	not NULL.
	* write.c (create_obj_attrs_section): Reformat.
	(create_note_reloc): New function - creates a relocation for a
	field in a GNU Build attribute note.
	(maybe_generate_build_notes): New function - created GNU Build
	attribute notes if none are present in the output file.
	(write_object_file): Call maybe_generate_build_notes.
	* configure.ac (--enable-generate-build-notes): New option.
	* NEWS: Announce the new feature.
	* doc/as.textinfo: Document the new option.
	* config.in: Regenerate.
	* configure: Regenerate.

binutils* readelf.c (is_32bit_abs_reloc): Support R_PARISC_DIR32 as a
	32-bit absolute reloc for the HPPA target.
	* testsuite/binutils-all/note-5.d: New test.
	* testsuite/binutils-all/note-5.s: Source file for new test.
	* testsuite/binutils-all/objcopy.exp: Run new test.
2018-04-26 15:12:42 +01:00
Christophe Lyon
aa68434129 [ld/testsuite] Fix pr2404 output.
2018-04-26  Christophe Lyon  <christophe.lyon@linaro.org>

	* testsuite/ld-elf/pr2404b.c (main): Adjust printf to account for
	new variable name.
	* testsuite/ld-elf/pr2404.out: Adjust expected output accordingly.
2018-04-26 13:44:33 +00:00
Pedro Alves
79188d8d27 Fix resolving GNU ifunc bp locations when inferior runs resolver
I noticed that if you set a breakpoint on an ifunc before the ifunc is
resolved, and then let the program call the ifunc, thus resolving it,
GDB end up with a location for that original breakpoint that is
pointing to the ifunc target, but it is left pointing to the first
address of the function, instead of after its prologue.  After
prologue is what you get if you create a new breakpoint at that point.

1) With no debug info for the target function:

  1.a) Set before resolving, and then program continued passed resolving:

    Num     Type           Disp Enb Address            What
    1       breakpoint     keep y   0x0000000000400753 <final>

  1.b) Breakpoint set after inferior resolved ifunc:

    Num     Type           Disp Enb Address            What
    2       breakpoint     keep y   0x0000000000400757 <final+4>


2) With debug info for the target function:

   1.a) Set before resolving, and then program continued passed resolving:

     Num     Type           Disp Enb Address            What
     1       breakpoint     keep y   0x0000000000400753 in final at gdb/testsuite/gdb.base/gnu-ifunc-final.c:20

   1.b) Breakpoint set after inferior resolved ifunc:

     Num     Type           Disp Enb Address            What
     2       breakpoint     keep y   0x000000000040075a in final at gdb/testsuite/gdb.base/gnu-ifunc-final.c:21

The problem is that elf_gnu_ifunc_resolver_return_stop (called by the
internal breakpoint that traps the resolver returning) does not agree
with linespec.c:minsym_found.  It does not skip to the function's
start line (i.e., past the prologue).  We can now use the
find_function_start_sal overload added by the previous commmit to fix
this.

New tests included, which fail before the patch, and pass afterwards.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* elfread.c (elf_gnu_ifunc_resolver_return_stop): Use
	find_function_start_sal instead of find_pc_line.

gdb/testsuite/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* gdb.base/gnu-ifunc.exp (set-break): Test that GDB resolves
	ifunc breakpoint locations correctly of ifunc breakpoints set
	while the program resolves the ifunc.
2018-04-26 13:12:09 +01:00
Pedro Alves
c7075ad503 Extend GNU ifunc testcases
This patch extends/rewrites the gdb.base/gnu-ifunc.exp testcase to
cover the many different fixes in earlier patches.  (This was actually
what encovered most of the problems.)

The current testcase uses an ifunc symbol with the same name as the
ifunc resolver symbol and makes sure to compile the ifunc resolver
without debug info.  That does not model how ifuncs are implemented in
gcc/ifunc nowadays.  Instead, what we have is that the glibc ifunc
resolvers nowadays are written in C and end up with debug info.

Also, in some cases the ifunc target is written in assembly, but in
other cases it's written in C.  In the case of target function written
in C, if the target function has debug info, when we set a break on
the ifunc, we want to set it past the prologue of the target function.
Currently GDB gets that wrong.

To make sure we cover all the different scenarios, the testcase is
tweaked to cover all the different combinations of

 - An ifunc resolver with the same name as the user-visible symbol vs
   an ifunc resolver with a different name as the user-visible symbol.

 - ifunc resolver compiled with and without debug info.

 - ifunc target function compiled with and without debug info.

The testcase currently sets breakpoints on ifuncs, calls ifunc
functions, steps into ifunc functions, etc.  After this series, this
all works and the testcase passes cleanly.

While working on this, I noticed that "b gnu_ifunc" before and after
the inferior resolved the ifunc would end up with a breakpoint with
different locations.  That's now covered by new tests inside the new
"set-break" procedure.

It also tests other things like making sure we can't call an ifunc
without a return-type case if we don't know the type of the target.
And making sure that we pass enough arguments when we do know the
type.

gdb/testsuite/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* gdb.base/gnu-ifunc-final.c: New file.
	* gdb.base/gnu-ifunc.c (final): Delete, moved to gnu-ifunc-final.c.
	* gdb.base/gnu-ifunc.exp (executable): Delete.
	(staticexecutable): Adjust.
	(lib_opts, exec_opts): Delete.
	(make_binsuffix, build, set-break): New procedures.
	(misc_tests): New, with tests factored out from the top level.
	(top level): Test different combinations of ifunc resolver name,
	resolver with and with debug info, and ifunc target with and
	without debug info.  Wrap static tests with with_target_prefix.
2018-04-26 13:11:09 +01:00
Pedro Alves
bfa5bd2ab3 PPC64: always make synthetic .text symbols for GNU ifunc symbols
If you create an ifunc using GCC's __attribute__ ifunc, like:

 extern int gnu_ifunc (int arg);
 static int gnu_ifunc_target (int arg) { return 0; }
 __typeof (gnu_ifunc) *gnu_ifunc_resolver (unsigned long hwcap) { return gnu_ifunc_target; }
 __typeof (gnu_ifunc) gnu_ifunc __attribute__ ((ifunc ("gnu_ifunc_resolver")));

then you end up with two (function descriptor) symbols, one for the
ifunc itself, and another for the resolver:

   (...)
   12: 0000000000020060    104 FUNC    GLOBAL DEFAULT       18 gnu_ifunc_resolver
   (...)
   16: 0000000000020060    104 GNU_IFUNC GLOBAL DEFAULT       18 gnu_ifunc
   (...)

Both ifunc and resolver symbols have the same address/value, so
ppc64_elf_get_synthetic_symtab only creates a synthetic text symbol
for one of them.  In the case above, it ends up being created for the
resolver, only:

  (gdb) maint print msymbols
  (...)
  [ 7] t 0x980 .frame_dummy section .text
  [ 8] T 0x9e4 .gnu_ifunc_resolver section .text
  [ 9] T 0xa58 __glink_PLTresolve section .text
  (...)

GDB needs to know when a program stepped into an ifunc resolver, so
that it can know whether to step past the resolver into the target
function without the user noticing.  The way GDB does it is my
checking whether the current PC points to an ifunc symbol (since
resolver and ifunc have the same address by design).

The problem is then that ppc64_elf_get_synthetic_symtab never creates
the synchetic symbol for the ifunc, so GDB stops stepping at the
resolver (in a test added by the following patch):

  (gdb) step
  gnu_ifunc_resolver (hwcap=21) at gdb/testsuite/gdb.base/gnu-ifunc-lib.c:33
  33      {
  (gdb) FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: final_debug=0: step

After this commit, we get:

  [ 8] i 0x9e4 .gnu_ifunc section .text
  [ 9] T 0x9e4 .gnu_ifunc_resolver section .text

And stepping an ifunc call takes to the final function:
  (gdb) step
  0x00000000100009e8 in .final ()
  (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: final_debug=0: step

An alternative to touching bfd I considered was for GDB to check
whether there's an ifunc data symbol / function descriptor that points
to the current PC, whenever the program stops, but discarded it
because we'd have to do a linear scan over .opd over an over to find a
matching function descriptor for the current PC.  At that point I
considered caching that info, but quickly dismissed it as then that
has no advantage (memory or performance) over just creating the
synthetic ifunc text symbol in the first place.

I ran the binutils and ld testsuites on PPC64 ELFv1 (machine gcc110 on
the GCC compile farm), and saw no regressions.  This commit is part of
a GDB patch series that includes GDB tests that fail without this fix.

bfd/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't consider
	ifunc and non-ifunc symbols duplicates.
2018-04-26 13:09:40 +01:00
Pedro Alves
f50776aad5 For PPC64/ELFv1: Introduce mst_data_gnu_ifunc
Running the new tests added later in the series on PPC64 (ELFv1)
revealed that the current ifunc support needs a bit of a design rework
to work properly on PPC64/ELFv1, as most of the new tests fail.  The
ifunc support only kind of works today if the ifunc symbol and the
resolver have the same name, as is currently tested by the
gdb.base/gnu-ifunc.exp testcase, which is unlike how ifuncs are
written nowadays.

The crux of the problem is that ifunc symbols are really function
descriptors, not text symbols:

   44: 0000000000020060    104 FUNC    GLOBAL DEFAULT       18 gnu_ifunc_resolver
   54: 0000000000020060    104 GNU_IFUNC GLOBAL DEFAULT     18 gnu_ifunc

But, currently GDB only knows about ifunc symbols that are text
symbols.  GDB's support happens to work in practice for PPC64 when the
ifunc and resolver are one and only, like in the current
gdb.base/gnu-ifunc.exp testcase:

   15: 0000000000020060    104 GNU_IFUNC GLOBAL DEFAULT       18 gnu_ifunc

because in that case, the synthetic ".gnu_ifunc" entry point text
symbol that bfd creates from the actual GNU ifunc "gnu_ifunc" function
(descriptor) symbol ends up with the the "is a gnu ifunc" flag set /
copied over:

  (gdb) maint print msymbols
  ...
  [ 8] i 0x9c4 .gnu_ifunc section .text                <<< mst_text_gnu_ifunc
  ...
  [29] D 0x20060 gnu_ifunc section .opd  crtstuff.c    <<< mst_data

But, if the resolver gets a distinct symbol/name from the ifunc
symbol, then we end up with this:

  (gdb) maint print msymbols
  [ 8] T 0x9e4 .gnu_ifunc_resolver section .text               <<< mst_text
  ...
  [29] D 0x20060 gnu_ifunc section .opd  crtstuff.c            <<< mst_data
  [30] D 0x20060 gnu_ifunc_resolver section .opd  crtstuff.c   <<< mst_data

I have a follow up bfd patch that turns that into:

   (gdb) maint print msymbols
+  [ 8] i 0x9e4 .gnu_ifunc section .text               <<< mst_text_gnu_ifunc
   [ 8] T 0x9e4 .gnu_ifunc_resolver section .text      <<< mst_text
   ...
   [29] D 0x20060 gnu_ifunc section .opd  crtstuff.c
   [30] D 0x20060 gnu_ifunc_resolver section .opd  crtstuff.c

but that won't help everything.  We still need this patch.

Specifically, when we do a symbol lookup by name, like e.g., to call a
function (see c-exp.y hunk), e.g., "p gnu_ifunc()", then we need to
know that the found "gnu_ifunc" minimal symbol is an ifunc in order to
do some special processing.  But, on PPC, that lookup by name finds
the function descriptor symbol, which presently is just a mst_data
symbol, while at present, we look for mst_text_gnu_ifunc symbols to
decide whether to do special GNU ifunc processing.  In most of those
places, we could try to resolve the function descriptor with
gdbarch_convert_from_func_ptr_addr, and then lookup the minimal symbol
at the resolved PC, see if that finds a minimal symbol of type
mst_text_gnu_ifunc.  If so, then we could assume that the original
mst_dadta / function descriptor "gnu_ifunc" symbol was an ifunc.  I
tried it, and it mostly works, even if it's not the most efficient.

However, there's one case that can't work with such a design -- it's
that of the user calling the ifunc resolver directly to debug it, like
"p gnu_ifunc_resolver(0)", expecting that to return the function
pointer of the final function (which is exercised by the new tests
added later).  In this case, with the not-fully-working solution, we'd
resolve the function descriptor, find that there's an
mst_text_gnu_ifunc symbol for the resolved address, and proceed
calling the function as if we tried to call "gnu_ifunc", the
user-visible GNU ifunc symbol, instead of the resolver.  I.e., it'd be
impossible to call the resolver directly as a normal function.

Introducing mst_data_gnu_ifunc eliminates the need for several
gdbarch_convert_from_func_ptr_addr calls, and, fixes the "call
resolver directly" use case mentioned above too.  It's the cleanest
approach I could think of.

In sum, we make GNU ifunc function descriptor symbols get a new
"mst_data_gnu_ifunc" minimal symbol type instead of the bare mst_data
type.  So when symbol lookup by name finds such a minimal symbol, we
know we found an ifunc symbol, without resolving the entry/text
symbol.  If the user calls the the resolver symbol instead, like "p
gnu_ifunc_resolver(0)", then we'll find the regular mst_data symbol
for "gnu_ifunc_resolver", and we'll call the resolver function as just
another regular function.

With this, most of the GNU ifunc tests added by a later patch pass on
PPC64 too.  The following bfd patch fixes the remaining issues.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (set_breakpoint_location_function): Handle
	mst_data_gnu_ifunc.
	* c-exp.y (variable production): Handle mst_data_gnu_ifunc.
	* elfread.c (elf_symtab_read): Give data symbols with
	BSF_GNU_INDIRECT_FUNCTION set mst_data_gnu_ifunc type.
	(elf_rel_plt_read): Update comment.
	* linespec.c (convert_linespec_to_sals): Handle
	mst_data_gnu_ifunc.
	(minsym_found): Handle mst_data_gnu_ifunc.
	* minsyms.c (msymbol_is_function, minimal_symbol_reader::record)
	(find_solib_trampoline_target): Handle mst_data_gnu_ifunc.
	* parse.c (find_minsym_type_and_address): Handle
	mst_data_gnu_ifunc.
	* symmisc.c (dump_msymbols): Handle mst_data_gnu_ifunc.
	* symtab.c (find_gnu_ifunc): Handle mst_data_gnu_ifunc.
	* symtab.h (minimal_symbol_type) <mst_text_gnu_ifunc>: Update
	comment.
	<mst_data_gnu_ifunc>: New enumerator.
2018-04-26 13:09:16 +01:00
Pedro Alves
20944a6e20 Fix stepping past GNU ifunc resolvers (introduce lookup_msym_prefer)
When we're stepping (with "step"), we want to skip trampoline-like
functions automatically, including GNU ifunc resolvers.  That is done
by infrun.c calling into:

  in_solib_dynsym_resolve_code
    -> svr4_in_dynsym_resolve_code
      -> in_gnu_ifunc_stub

A problem here is that if there's a regular text symbol at the same
address as the ifunc symbol, the minimal symbol lookup in
in_gnu_ifunc_stub may miss the GNU ifunc symbol:

(...)
    41: 000000000000071a    53 FUNC    GLOBAL DEFAULT   11 gnu_ifunc_resolver
(...)
    50: 000000000000071a    53 IFUNC   GLOBAL DEFAULT   11 gnu_ifunc
(...)

This causes this FAIL in the tests added later in the series:

 (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=0: final_debug=0: resolver received HWCAP
 set step-mode on
 (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=0: final_debug=0: set step-mode on
 step
 0x00007ffff7bd371a in gnu_ifunc_resolver () from build/gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-lib-1-0-0.so
 (gdb) FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=0: final_debug=0: step

Above, GDB simply thought that it stepped into a regular function, so
it stopped stepping, while it should have continued stepping past the
resolver.

The fix is to teach minimal symbol lookup to prefer GNU ifunc symbols
if desired.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Rename to ...
	(lookup_minimal_symbol_by_pc_section): ... this.  Replace
	'want_trampoline' parameter by a lookup_msym_prefer parameter.
	Handle it.
	(lookup_minimal_symbol_by_pc_section): Delete old implementation.
	(lookup_minimal_symbol_by_pc): Adjust.
	(in_gnu_ifunc_stub): Prefer GNU ifunc symbols.
	(lookup_solib_trampoline_symbol_by_pc): Adjust.
	* minsyms.h (lookup_msym_prefer): New enum.
	(lookup_minimal_symbol_by_pc_section): Replace 'want_trampoline'
	parameter by a lookup_msym_prefer parameter.
2018-04-26 13:08:47 +01:00
Pedro Alves
1adeb82266 For PPC64: elf_gnu_ifunc_record_cache: handle plt symbols in .text section
elf_gnu_ifunc_record_cache doesn't ever record anything on PPC64
(tested on gcc110 on the compile farm, CentOS 7.4, ELFv1), because
that expects to find PLT symbols in the .plt section, while there we
get:

  (gdb) info symbol 'gnu_ifunc@plt'
  gnu_ifunc@plt in section .text
                           ^^^^^

I guess that may be related to the comment in ppc-linux-tdep.c that
says "For secure PLT, stub is in .text".

In any case, this commit fixes the issue by making the function look
at the symbol name instead of at the section.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* elfread.c (elf_gnu_ifunc_record_cache): Check if the symbol name
	ends in "@plt" instead of looking at the symbol's section.
2018-04-26 13:08:01 +01:00
Pedro Alves
42ddae103c Factor out minsym_found/find_function_start_sal overload
I need to make the ifunc resolving code in elfread.c skip the target
function's prologue like minsym_found does.  I thought of factoring
that out to a separate function, but turns out there's already a
comment in find_function_start_sal that says that should agree with
minsym_found...

Instead of making sure the code agrees with a comment, factor out the
common code to a separate function and use it from both places.

Note that the current find_function_start_sal does a bit more than
minsym_found's equivalent (the "We always should ..." bit), though
that's probably a latent bug.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* linespec.c (minsym_found): Use find_function_start_sal CORE_ADDR
	overload.
	* symtab.c (find_function_start_sal(CORE_ADDR, obj_section *,bool)):
	New, factored out from ...
	(find_function_start_sal(symbol *, int)): ... this.  Reimplement
	and use bool.
	* symtab.h (find_function_start_sal(CORE_ADDR, obj_section *,bool)):
	New.
	(find_function_start_sal(symbol *, int)): Change boolean parameter
	type to bool.
2018-04-26 13:07:47 +01:00
Pedro Alves
a0aca7b0e1 Eliminate find_pc_partial_function_gnu_ifunc
Not used anywhere any longer.

If this is ever reinstated, note that this case:

	  cache_pc_function_is_gnu_ifunc = TYPE_GNU_IFUNC (SYMBOL_TYPE (f));

was incorrect in that regular symbols never have type marked as GNU
ifunc type, only minimal symbols.  At some point I had some fix that
checking the matching minsym here.  But in the end I ended up just
eliminating need for this function, so that fix was not necessary.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* blockframe.c (cache_pc_function_is_gnu_ifunc): Delete.  Remove
	all references.
	(find_pc_partial_function_gnu_ifunc): Rename to ...
	(find_pc_partial_function): ... this, and remove references to
	'is_gnu_ifunc_p'.
	(find_pc_partial_function): Delete old implementation.
	* symtab.h (find_pc_partial_function_gnu_ifunc): Delete.
2018-04-26 13:07:25 +01:00
Pedro Alves
76af0f2635 Breakpoints, don't skip prologue of ifunc resolvers with debug info
Without this patch, some of the tests added to gdb.base/gnu-ifunc.exp
by a following patch fail like so:

  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: set-break: before resolving: break gnu_ifunc
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: set-break: before resolving: info breakpoints
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: set-break: after resolving: break gnu_ifunc
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: set-break: after resolving: info breakpoints
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=1: set-break: before resolving: break gnu_ifunc
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=1: set-break: before resolving: info breakpoints
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=1: set-break: after resolving: break gnu_ifunc
  FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=1: set-break: after resolving: info breakpoints

All of them trigger iff:

 - you have debug info for the ifunc resolver.
 - the resolver and the user-visible symbol have the same name.

If you have an ifunc that has a resolver with the same name as the
user visible symbol, debug info for the resolver masks out the ifunc
minsym.  When you set a breakpoint by name on the user visible symbol,
GDB finds the DWARF symbol for the resolver, and thinking that it's a
regular function, sets a breakpoint location past its prologue.

Like so, location 1.2, before the ifunc is resolved by the inferior:

  (gdb) break gnu_ifunc
  Breakpoint 2 at 0x7ffff7bd36ea (2 locations)
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   <MULTIPLE>
  1.1                         y     0x00007ffff7bd36ea <gnu_ifunc>
  1.2                         y     0x00007ffff7bd36f2 in gnu_ifunc at src/gdb/testsuite/gdb.base/gnu-ifunc-lib.c:34
  (gdb)

And like so, location 2.2, if you set the breakpoint after the ifunc
is resolved by the inferior (to "final"):

  (gdb) break gnu_ifunc
  Breakpoint 5 at 0x400757 (2 locations)
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   <MULTIPLE>
  2.1                         y     0x000000000040075a in final at src/gdb/testsuite/gdb.base/gnu-ifunc-resd.c:21
  2.2                         y     0x00007ffff7bd36f2 in gnu_ifunc at src/gdb/testsuite/gdb.base/gnu-ifunc-lib.c:34
  (gdb)

I don't think this is right because when users set a breakpoint at an
ifunc, they don't care about debugging the resolver.  Instead what you
should is a single location for the ifunc in the first case, and a
single location of the ifunc target in the second case.

gdb/ChangeLog:
2018-04-26  Pedro Alves  <palves@redhat.com>

	* linespec.c (struct bound_minimal_symbol_search_key): New.
	(convert_linespec_to_sals): Sort minimal symbols earlier.  Don't
	skip first line if we found a GNU ifunc minimal symbol by name.
	(compare_msymbols): Change parameters to work with a destructured
	lhs minsym.
	(compare_msymbols_for_qsort, compare_msymbols_for_bsearch): New
	functions.
2018-04-26 13:06:53 +01:00