binutils_os216

Fork

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:
yyyy-mm-dd 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:
yyyy-mm-dd 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.

Extend GNU ifunc testcases

In v2:

- Renamed "resvd" -> "final", as I was constantly confusing myself.
- Tweaked tests for PPC64.

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:
yyyy-mm-dd 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.

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.

OK to apply?

bfd/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't consider
ifunc and non-ifunc symbols duplicates.

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:
yyyy-mm-dd 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.

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:
yyyy-mm-dd 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.

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:
yyyy-mm-dd 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.

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:
yyyy-mm-dd 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.

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:
yyyy-mm-dd 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.

Breakpoints, don't skip prologue of ifunc resolvers with debug info

In v2:

- The minsym/symbol matching in convert_linespec_to_sals is done
differently. The v1 bsearch method wouldn't work for PPC64, given
function descriptors. convert_linespec_to_sals will be touched
again later in the series, for PPC64.
- Moved declarations of locals closer to uses, because at some point
I managed to reuse 'i' in an inner loop messing the outer loop...

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:
yyyy-mm-dd 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.

Fix setting breakpoints on ifunc functions after they're already resolved

This fixes setting breakpoints on ifunc functions by name after the
ifunc has already been resolved.

In that case, if you have debug info for the ifunc resolver, without
the fix, then gdb puts a breakpoint past the prologue of the resolver,
instead of setting a breakpoint at the ifunc target:

break gnu_ifunc
Breakpoint 4 at 0x7ffff7bd36f2: file src/gdb/testsuite/gdb.base/gnu-ifunc-lib.c, line 34.
(gdb) continue
Continuing.
[Inferior 1 (process 13300) exited normally]
(gdb)

above we should have stopped at "final", but didn't because we never
resolved the ifunc to the final location.

If you don't have debug info for the resolver, GDB manages to resolve
the ifunc target, but, it should be setting a breakpoint after the
prologue of the final function, and instead what you get is that GDB
sets a breakpoint on the first address of the target function. With
the gnu-ifunc.exp tests added by a later patch, we get, without the
fix:

(gdb) break gnu_ifunc
Breakpoint 4 at 0x400753
(gdb) continue
Continuing.

Breakpoint 4, final (arg=1) at src/gdb/testsuite/gdb.base/gnu-ifunc-final.c:20
20 {

vs, fixed:

(gdb) break gnu_ifunc
Breakpoint 4 at 0x40075a: file src/gdb/testsuite/gdb.base/gnu-ifunc-final.c, line 21.
(gdb) continue
Continuing.

Breakpoint 4, final (arg=2) at src/gdb/testsuite/gdb.base/gnu-ifunc-final.c:21
21 return arg + 1;
(gdb)

Fix the problems above by moving the ifunc target resolving to
linespec.c, before we skip a function's prologue. We need to save
something in the sal, so that set_breakpoint_location_function knows
that it needs to create a bp_gnu_ifunc_resolver bp_location. Might as
well just save a pointer to the minsym.

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* breakpoint.c (set_breakpoint_location_function): Don't resolve
ifunc targets here. Instead, if we have an ifunc minsym, use its
address/name.
(add_location_to_breakpoint): Store the minsym and the objfile in
the breakpoint location.
* breakpoint.h (bp_location) <msymbol, objfile>: New fields.
* linespec.c (minsym_found): Resolve GNU ifunc targets here.
Record the minsym in the sal.
* symtab.h (symtab_and_line) <msymbol>: New field.

Fix elf_gnu_ifunc_resolve_by_got buglet

The next patch will add a call to elf_gnu_ifunc_resolve_by_got that
trips on a latent buglet -- the function is writing to its output
parameter even if the address wasn't found, confusing the caller. The
function's intro comment says:

/* Try to find the target resolved function entry address of a STT_GNU_IFUNC
function NAME. If the address is found it is stored to *ADDR_P (if ADDR_P
is not NULL) and the function returns 1. It returns 0 otherwise.

So fix the function accordingly.

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* elfread.c (elf_gnu_ifunc_resolve_by_got): Don't write to *ADDR_P
unless we actually resolved the ifunc.

Calling ifunc functions when resolver has debug info, user symbol same name

In v2:

- find_gnu_ifunc is now based on name search. Need exposed by
PP64 (see later patches in the series).
- Added iterate_over_minimal_symbols function_view overload for
that, and made it possible to stop the search if the callback says
so.

If the GNU ifunc resolver has the same name as the user visible
symbol, and the resolver has debug info, then the DWARF info for the
resolver masks the ifunc minsym. In that scenario, if you try calling
the ifunc from GDB, you call the resolver instead. With the
gnu-ifunc.exp testcase added in a following patch, you'd see:

(gdb) p gnu_ifunc (3)
$1 = (int (*)(int)) 0x400753 <final>
(gdb) FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: p gnu_ifunc (3)
^^^^^^^^^^^^^^^^

That is, we called the ifunc resolver manually, which returned a
pointer to the ifunc target function ("final"). The "final" symbol is
the function that GDB should have called automatically,

~~~~~~~~~~~~
int
final (int arg)
{
return arg + 1;
}
~~~~~~~~~

which is what happens if you don't have debug info for the resolver:

(gdb) p gnu_ifunc (3)
$1 = 4
(gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=0: resolved_debug=1: p gnu_ifunc (3)
^^^^^^^^^^^^^^^^

or if the resolver's symbol has a different name from the ifunc (as is
the case with modern uses of ifunc via __attribute__ ifunc, such as
glibc uses):

(gdb) p gnu_ifunc (3)
$1 = 4
(gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: resolved_debug=0: p gnu_ifunc (3)
^^^^^^^^^^^^^^^

in which case after this patch, you can still call the resolver
directly if you want:

(gdb) p gnu_ifunc_resolver (3)
$1 = (int (*)(int)) 0x400753 <final>

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* c-exp.y (variable production): Prefer ifunc minsyms over
regular function symbols.
* symtab.c (find_gnu_ifunc): New function.
* minsyms.h (lookup_msym_prefer): New enum.
(lookup_minimal_symbol_by_pc_section): Replace 'want_trampoline'
parameter by a lookup_msym_prefer parameter.
* symtab.h (find_gnu_ifunc): New declaration.

Calling ifunc functions when target has no debug info but resolver has

After the previous patch, on Fedora 27 (glibc 2.26), if you try
calling strlen in the inferior, you now get:

(top-gdb) p strlen ("hello")
'__strlen_avx2' has unknown return type; cast the call to its declared return type

This is correct, because __strlen_avx2 is written in assembly.

We can improve on this though -- if the final ifunc resolved/target
function has no debug info, but the ifunc _resolver_ does have debug
info, we can try extracting the final function's type from the type
that the resolver returns. E.g.,:

typedef size_t (*strlen_t) (const char*);

size_t my_strlen (const char *) { /* some implementation */ }
strlen_t strlen_resolver (unsigned long hwcap) { return my_strlen; }

extern size_t strlen (const char *s);
__typeof (strlen) strlen __attribute__ ((ifunc ("strlen_resolver")));

In the strlen example above, the resolver returns strlen_t, which is a
typedef for pointer to a function that returns size_t. "strlen_t" is
the type of both the user-visible "strlen", and of the the target
function that implements it.

This patch teaches GDB to extract that type.

This is done for actual inferior function calls (in infcall.c), and
for ptype (in eval_call). By the time we get to either of these
places, we've already lost the original symbol/minsym, and only have
values and types to work with. Hence the changes to c-exp.y and
evaluate_var_msym_value, to ensure that we propagate the ifunc
minsymbol's info.

The change to make ifunc symbols have no/unknown return type exposes a
latent problem -- gdb.compile/compile-ifunc.exp calls a no-debug-info
function, but we did not warn about it. The test is fixed by this
commit too.

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* blockframe.c (find_gnu_ifunc_target_type): New function.
(find_function_type): New.
* eval.c (evaluate_var_msym_value): For GNU ifunc types, always
return a value with a memory address.
(eval_call): For calls to GNU ifunc functions, try to find the
type of the target function from the type that the resolver
returns.
* gdbtypes.c (objfile_type): Don't install a return type for ifunc
symbols.
* infcall.c (find_function_return_type): Delete.
(find_function_addr): Add 'function_type' parameter. For calls to
GNU ifunc functions, try to find the type of the target function
from the type that the resolver returns, and return it via
FUNCTION_TYPE.
(call_function_by_hand_dummy): Adjust to use the function type
returned by find_function_addr.
(find_function_addr): Add 'function_type' parameter and move
description here.
* symtab.h (find_function_type, find_gnu_ifunc_target_type): New
declarations.

gdb/testsuite/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* gdb.compile/compile-ifunc.exp: Also expect "function has unknown
return type" warnings.

Fix calling ifunc functions when resolver has debug info and different name

Currently, on Fedora 27 (glibc 2.26), if you try to call strlen in the
inferior you get:

(gdb) p strlen ("hello")
$1 = (size_t (*)(const char *)) 0x7ffff554aac0 <__strlen_avx2>

strlen is an ifunc function, and what we see above is the result of
calling the ifunc resolver in the inferior. That returns a pointer to
the actual target function that implements strlen on my machine. GDB
should have turned around and called the resolver automatically
without the user noticing.

This is was caused by commit:

commit bf223d3e808e6fec9ee165d3d48beb74837796de
Date: Mon Aug 21 11:34:32 2017 +0100

Handle function aliases better (PR gdb/19487, errno printing)

which added the find_function_alias_target call to c-exp.y, to try to
find an alias with debug info for a minsym. For ifunc symbols, that
finds the ifunc's resolver if it has debug info (in the example it's
called "strlen_ifunc"), with the result that GDB calls that as a
regular function.

After this commit, we get now get:

(top-gdb) p strlen ("hello")
'__strlen_avx2' has unknown return type; cast the call to its declared return type

Which is correct, because __strlen_avx2 is written in assembly.
That'll be improved in a following patch, though.

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* c-exp.y (variable production): Skip finding an alias for ifunc
symbols.

Fix breakpoints in ifunc after inferior resolved it (@got.plt symbol creation)

In v2: - reworked to keep supporting rel.plt sections for .plt, and
to handle jump slot offsets pointing to .plt.

Setting a breakpoint on an ifunc symbol after the ifunc has already
been resolved by the inferior should result in creating a breakpoint
location at the ifunc target. However, that's not what happens on
current Fedora:

(gdb) n
53 i = gnu_ifunc (1); /* break-at-call */
(gdb)
54 assert (i == 2);
(gdb) b gnu_ifunc
Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7bd36ee
(gdb) info breakpoints
Num Type Disp Enb Address What
2 STT_GNU_IFUNC resolver keep y 0x00007ffff7bd36ee <gnu_ifunc+4>

The problem is that elf_gnu_ifunc_resolve_by_got never manages to
resolve an ifunc target. The reason is that GDB never actually
creates the internal got.plt symbols:

(gdb) p 'gnu_ifunc@got.plt'
No symbol "gnu_ifunc@got.plt" in current context.

and this is because GDB expects that rela.plt has relocations for
.plt, while it actually has relocations for .got.plt:

Relocation section [10] '.rela.plt' for section [22] '.got.plt' at offset 0x570 contains 2 entries:
Offset Type Value Addend Name
0x0000000000601018 X86_64_JUMP_SLOT 000000000000000000 +0 __assert_fail
0x0000000000601020 X86_64_JUMP_SLOT 000000000000000000 +0 gnu_ifunc


Using an older system on the GCC compile farm (machine gcc15, an
x86-64 running Debian 6.0.8, with GNU ld 2.20.1), we see that it used
to be that we'd get a .rela.plt section for .plt:

Relocation section [ 9] '.rela.plt' for section [11] '.plt' at offset 0x578 contains 3 entries:
Offset Type Value Addend Name
0x0000000000600cc0 X86_64_JUMP_SLOT 000000000000000000 +0 __assert_fail
0x0000000000600cc8 X86_64_JUMP_SLOT 000000000000000000 +0 __libc_start_main
0x0000000000600cd0 X86_64_JUMP_SLOT 000000000000000000 +0 gnu_ifunc

Those offsets did point into .got.plt, as seen with objdump -h:

20 .got.plt 00000030 0000000000600ca8 0000000000600ca8 00000ca8 2**3
CONTENTS, ALLOC, LOAD, DATA

I also tested on gcc110 on the compile farm (PPC64 running CentOS
7.4.1708, with GNU ld 2.25.1), and there we see instead:

Relocation section [ 9] '.rela.plt' for section [23] '.plt' at offset 0x5d0 contains 4 entries:
Offset Type Value Addend Name
0x0000000010020148 PPC64_JMP_SLOT 000000000000000000 +0 __libc_start_main
0x0000000010020160 PPC64_JMP_SLOT 000000000000000000 +0 __gmon_start__
0x0000000010020178 PPC64_JMP_SLOT 000000000000000000 +0 __assert_fail
0x0000000010020190 PPC64_JMP_SLOT 000000000000000000 +0 gnu_ifunc

But note that those offsets point into .plt, not .got.plt, as seen
with objdump -h:

22 .plt 00000078 0000000010020130 0000000010020130 00010130 2**3
ALLOC

This commit makes us support all the different combinations above.

With that addressed, we now get:

(gdb) p 'gnu_ifunc@got.plt'
$1 = (<text from jump slot in .got.plt, no debug info>) 0x400753 <final>

And setting a breakpoint on the ifunc finds the ifunc target:

(gdb) b gnu_ifunc
Breakpoint 2 at 0x400753
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000400753 <final>

gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>

* elfread.c (elf_rel_plt_read): Look for relocations for .got.plt too.
not .plt.

Fix gdb.base/fork-running-state.exp race

On my multi-target branch I was occasionaly seeing a FAIL like this:

(gdb) PASS: gdb.base/fork-running-state.exp: detach-on-fork=off: follow-fork=parent: non-stop: kill parent
[Inferior 2 (process 32672) exited normally]
kill inferior 2
warning: Inferior ID 2 is not running.
(gdb) FAIL: gdb.base/fork-running-state.exp: detach-on-fork=off: follow-fork=parent: non-stop: kill child (the program exited)
... other similar fails ...

Turns out to be a testcase bug/race. A tweak like this increases the
changes of hitting the race substancially:

--- a/gdb/testsuite/gdb.base/fork-running-state.c
+++ b/gdb/testsuite/gdb.base/fork-running-state.c
@@ -29,7 +29,7 @@ fork_child (void)
{
while (1)
{
- sleep (1);
+ usleep (100);


The testcase has two processes, parent and child fork. The problem is
that the child exits itself if it notices the parent is gone, but the
testcase .exp does not expect that.

I first wrote a patch that handled the different combinations of
non-stop/detach-on-fork/follow-fork/schedule-multiple, making the .exp
file know when to expect the child to exit itself vs when to kill it
explicitly, but the result was that the code to kill the parent and
child was getting about as large as the test code that is the actual
point of the testcase, above the kills.

So I scratched that approach and came up with a simpler patch --
simply make the child not exit itself when the parent exits.

The .exp file is going to kill both parent and child explicitly, and,
main() already calls alarm() as a safeguard. I don't think we lose
anything.

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

* gdb.base/fork-running-state.c (fork_child): Don't exit if parent
exits. Instead loop running forever.
(fork_parent): Run forever too.

Replace finish_thread_state_cleanup with a RAII class

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

* gdbthread.h (finish_thread_state_cleanup): Delete declaration.
(scoped_finish_thread_state): New class.
* infcmd.c (run_command_1): Use it instead of finish_thread_state
cleanup.
* infrun.c (proceed, prepare_for_detach, wait_for_inferior)
(fetch_inferior_event, normal_stop): Likewise.
* thread.c (finish_thread_state_cleanup): Delete.

Fix some strip test fails on nds32 and pru

Fixes these fails:
nds32le-linux +FAIL: binutils-all/strip-14
nds32le-linux +FAIL: binutils-all/strip-15
pru-elf +FAIL: binutils-all/strip-14
pru-elf +FAIL: binutils-all/strip-15

strip-13 fails on nds32 due to an assertion failure and out of bounds
access to nds32_elf_howto_table.

* testsuite/binutils-all/objcopy.exp (strip-14, strip-15): Choose
reloc=11 for pru and reloc=50 for nds32.
* testsuite/binutils-all/strip-15.d: Accept 0xb reloc number.

Automatic date update in version.in

Add selftests for range_contains and insert_into_bit_range_vector

Add some selftests for these two functions. To to make it easier to
compare sequences of ranges, add operator== and operator!= to compare
two gdb::array_view, and add operator== in struct range.

gdb/ChangeLog:

* value.c: Include "selftest.h" and "common/array-view.h".
(struct range) <operator ==>: New.
(test_ranges_contain): New.
(check_ranges_vector): New.
(test_insert_into_bit_range_vector): New.
(_initialize_values): Register selftests.
* common/array-view.h (operator==, operator!=): New.

Use an std::vector for inline_states

This patch replaces VEC(inline_state) with std::vector<inline_state> and
adjusts the code that uses it.

gdb/ChangeLog:

* common/gdb_vecs.h (unordered_remove): Add overload that takes
an iterator.
* inline-frame.c: Include <algorithm>.
(struct inline_state): Add constructor.
(inline_state_s): Remove.
(DEF_VEC_O(inline_state_s)): Remove.
(inline_states): Change type to std::vector.
(find_inline_frame_state): Adjust to std::vector.
(allocate_inline_frame_state): Remove.
(clear_inline_frame_state): Adjust to std::vector.
(skip_inline_frames): Adjust to std::vector.

Remove VEC(tsv_s), use std::vector instead

This patch removes VEC(tsv_s), using an std::vector instead. I C++ified
trace_state_variable a bit in the process, using std::string for the
name. I also thought it would be nicer to pass a const reference to
target_download_trace_state_variable, since we know it will never be
NULL. This highlighted that the make-target-delegates script didn't
handle references well, so I adjusted this as well. It will surely be
useful in the future.

gdb/ChangeLog:

* tracepoint.h (struct trace_state_variable): Add constructor.
<name>: Change type to std::string.
* tracepoint.c (tsv_s): Remove.
(DEF_VEC_O(tsv_s)): Remove.
(tvariables): Change to std::vector.
(create_trace_state_variable): Adjust to std::vector.
(find_trace_state_variable): Likewise.
(find_trace_state_variable_by_number): Likewise.
(delete_trace_state_variable): Likewise.
(trace_variable_command): Adjust to std::string.
(delete_trace_variable_command): Likewise.
(tvariables_info_1): Adjust to std::vector.
(save_trace_state_variables): Likewise.
(start_tracing): Likewise.
(merge_uploaded_trace_state_variables): Adjust to std::vector
and std::string.
* target.h (struct target_ops)
<to_download_trace_state_variable>: Pass reference to
trace_state_variable.
* target-debug.h (target_debug_print_const_trace_state_variable_r): New.
* target-delegates.c: Re-generate.
* mi/mi-interp.c (mi_tsv_created): Adjust to std::string.
(mi_tsv_deleted): Likewise.
* mi/mi-main.c (mi_cmd_trace_frame_collected): Likewise.
* remote.c (remote_download_trace_state_variable): Change
pointer to reference and adjust.
* make-target-delegates (parse_argtypes): Handle references.
(write_function_header): Likewise.
(munge_type): Likewise.

Adapt and integrate string_view tests

The previous patch copied the string_view tests from libstdc++. This
patch adjusts them in a similar way that the libstdc++ optional tests
are integrated in our unit test suite.

Not all tests are used, some of them require language features not
present in c++11. For example, we can't use a string_view constructor
where the length is not explicit in a constexpr, because
std::char_traits::length is not a constexpr itself (it is in c++17
though). Nevertheless, a good number of tests are integrated, which
covers pretty well the string_view features.

gdb/ChangeLog:

* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
string_view-selftests.c.
* unittests/basic_string_view/capacity/1.cc: Adapt to GDB
testsuite.
* unittests/basic_string_view/cons/char/1.cc: Likewise.
* unittests/basic_string_view/cons/char/2.cc: Likewise.
* unittests/basic_string_view/cons/char/3.cc: Likewise.
* unittests/basic_string_view/element_access/char/1.cc:
Likewise.
* unittests/basic_string_view/element_access/char/empty.cc:
Likewise.
* unittests/basic_string_view/element_access/char/front_back.cc:
Likewise.
* unittests/basic_string_view/inserters/char/2.cc: Likewise.
* unittests/basic_string_view/modifiers/remove_prefix/char/1.cc:
Likewise.
* unittests/basic_string_view/modifiers/remove_suffix/char/1.cc:
Likewise.
* unittests/basic_string_view/modifiers/swap/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/compare/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/compare/char/13650.cc:
Likewise.
* unittests/basic_string_view/operations/copy/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/data/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/find/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/find/char/2.cc:
Likewise.
* unittests/basic_string_view/operations/find/char/3.cc:
Likewise.
* unittests/basic_string_view/operations/find/char/4.cc:
Likewise.
* unittests/basic_string_view/operations/rfind/char/1.cc:
Likewise.
* unittests/basic_string_view/operations/rfind/char/2.cc:
Likewise.
* unittests/basic_string_view/operations/rfind/char/3.cc:
Likewise.
* unittests/basic_string_view/operations/substr/char/1.cc:
Likewise.
* unittests/basic_string_view/operators/char/2.cc: Likewise.
* unittests/string_view-selftests.c: New file.

Copy string_view tests from libstdc++

This patch copies the string_view tests from the gcc repository (commit
02a4441f002c).

${gcc}/libstdc++-v3/testsuite/21_strings/basic_string_view ->
${binutils-gdb}/gdb/unittests/basic_string_view

The local modifications are done in the following patch, so that it's
easier to review them.

gdb/ChangeLog:

* unittests/basic_string_view/capacity/1.cc: New file.
* unittests/basic_string_view/capacity/empty_neg.cc: New file.
* unittests/basic_string_view/cons/char/1.cc: New file.
* unittests/basic_string_view/cons/char/2.cc: New file.
* unittests/basic_string_view/cons/char/3.cc: New file.
* unittests/basic_string_view/cons/wchar_t/1.cc: New file.
* unittests/basic_string_view/cons/wchar_t/2.cc: New file.
* unittests/basic_string_view/cons/wchar_t/3.cc: New file.
* unittests/basic_string_view/element_access/char/1.cc: New file.
* unittests/basic_string_view/element_access/char/2.cc: New file.
* unittests/basic_string_view/element_access/char/empty.cc: New file.
* unittests/basic_string_view/element_access/char/front_back.cc: New file.
* unittests/basic_string_view/element_access/wchar_t/1.cc: New file.
* unittests/basic_string_view/element_access/wchar_t/2.cc: New file.
* unittests/basic_string_view/element_access/wchar_t/empty.cc: New file.
* unittests/basic_string_view/element_access/wchar_t/front_back.cc: New file.
* unittests/basic_string_view/include.cc: New file.
* unittests/basic_string_view/inserters/char/1.cc: New file.
* unittests/basic_string_view/inserters/char/2.cc: New file.
* unittests/basic_string_view/inserters/char/3.cc: New file.
* unittests/basic_string_view/inserters/pod/10081-out.cc: New file.
* unittests/basic_string_view/inserters/wchar_t/1.cc: New file.
* unittests/basic_string_view/inserters/wchar_t/2.cc: New file.
* unittests/basic_string_view/inserters/wchar_t/3.cc: New file.
* unittests/basic_string_view/literals/types.cc: New file.
* unittests/basic_string_view/literals/values.cc: New file.
* unittests/basic_string_view/modifiers/remove_prefix/char/1.cc: New file.
* unittests/basic_string_view/modifiers/remove_prefix/wchar_t/1.cc: New file.
* unittests/basic_string_view/modifiers/remove_suffix/char/1.cc: New file.
* unittests/basic_string_view/modifiers/remove_suffix/wchar_t/1.cc: New file.
* unittests/basic_string_view/modifiers/swap/char/1.cc: New file.
* unittests/basic_string_view/modifiers/swap/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/compare/char/1.cc: New file.
* unittests/basic_string_view/operations/compare/char/13650.cc: New file.
* unittests/basic_string_view/operations/compare/char/2.cc: New file.
* unittests/basic_string_view/operations/compare/char/70483.cc: New file.
* unittests/basic_string_view/operations/compare/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/compare/wchar_t/13650.cc: New file.
* unittests/basic_string_view/operations/compare/wchar_t/2.cc: New file.
* unittests/basic_string_view/operations/copy/char/1.cc: New file.
* unittests/basic_string_view/operations/copy/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/data/char/1.cc: New file.
* unittests/basic_string_view/operations/data/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/find/char/1.cc: New file.
* unittests/basic_string_view/operations/find/char/2.cc: New file.
* unittests/basic_string_view/operations/find/char/3.cc: New file.
* unittests/basic_string_view/operations/find/char/4.cc: New file.
* unittests/basic_string_view/operations/find/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/find/wchar_t/2.cc: New file.
* unittests/basic_string_view/operations/find/wchar_t/3.cc: New file.
* unittests/basic_string_view/operations/find/wchar_t/4.cc: New file.
* unittests/basic_string_view/operations/rfind/char/1.cc: New file.
* unittests/basic_string_view/operations/rfind/char/2.cc: New file.
* unittests/basic_string_view/operations/rfind/char/3.cc: New file.
* unittests/basic_string_view/operations/rfind/wchar_t/1.cc: New file.
* unittests/basic_string_view/operations/rfind/wchar_t/2.cc: New file.
* unittests/basic_string_view/operations/rfind/wchar_t/3.cc: New file.
* unittests/basic_string_view/operations/string_conversion/1.cc: New file.
* unittests/basic_string_view/operations/substr/char/1.cc: New file.
* unittests/basic_string_view/operations/substr/wchar_t/1.cc: New file.
* unittests/basic_string_view/operators/char/2.cc: New file.
* unittests/basic_string_view/operators/wchar_t/2.cc: New file.
* unittests/basic_string_view/range_access/char/1.cc: New file.
* unittests/basic_string_view/range_access/wchar_t/1.cc: New file.
* unittests/basic_string_view/requirements/explicit_instantiation/1.cc: New file.
* unittests/basic_string_view/requirements/explicit_instantiation/char/1.cc: New file.
* unittests/basic_string_view/requirements/explicit_instantiation/char16_t/1.cc: New file.
* unittests/basic_string_view/requirements/explicit_instantiation/char32_t/1.cc: New file.
* unittests/basic_string_view/requirements/explicit_instantiation/wchar_t/1.cc: New file.
* unittests/basic_string_view/requirements/typedefs.cc: New file.
* unittests/basic_string_view/typedefs.cc: New file.
* unittests/basic_string_view/types/1.cc: New file.

Add gdb::string_view

We had a few times the need for a data structure that does essentially
what C++17's std::string_view does, which is to give an std::string-like
interface (only the read-only operations) to an arbitrary character
buffer.

This patch adapts the files copied from libstdc++ by the previous patch
to integrate them with GDB. Here's a summary of the changes:

* Remove things related to wstring_view, u16string_view and
u32string_view (I don't think we need them, but we can always add them
later).

* Remove usages of _GLIBCXX_BEGIN_NAMESPACE_VERSION and
_GLIBCXX_END_NAMESPACE_VERSION.

* Put the code in the gdb namespace. I had to add a few "std::" in
front of std type usages.

* Change __throw_out_of_range_fmt() for error().

* Make gdb::string_view an alias of std::string_view when building
with >= c++17.

* Remove a bunch of constexpr, because they are not valid in c++11
(e.g. they are not a single return line).

* Use std::common_type<_Tp>::type instead of std::common_type_t<_Tp>,
because c++11 doesn't have the later.

* Remove the #pragma GCC system_header, since that silences some
warnings that we might want to have if we're doing something not
correctly.

* Remove operator ""sv. It would need a lot of work to make all
supported compilers happy, and we can easily live without it.

* Remove operator<<. It is implemented using __ostream_insert (a
libstdc++ internal). Bringing it in might be possible, but I don't
think that would be worth the effort, since we don't really use
streams at the moment.

* Replace internal libstdc++ asserts ( __glibcxx_assert and
__glibcxx_requires_string_len) with gdb_assert.

* Remove hash helpers, because they use libstdc++ internal functions.
If we need them we always import them later.

The string_view class in cli/cli-script.c is removed and its usage
replaced with the new gdb::string_view.

gdb/ChangeLog:

* common/gdb_string_view.h: Remove libstdc++ implementation
details, adjust to gdb reality.
* common/gdb_string_view.tcc: Likewise.
* cli/cli-script.c (struct string_view): Remove.
(user_args) <m_args>: Change element type to gdb::string_view.
(user_args::insert_args): Adjust.

Copy string_view files from libstdc++

This patch copies the following files from libstdc++ (commit
02a4441f002c):

${gcc}/libstdc++-v3/include/experimental/string_view
-> ${binutils-gdb}/gdb/common/gdb_string_view.h

${gcc}/libstdc++-v3/include/experimental/bits/string_view.tcc
-> ${binutils-gdb}/gdb/common/gdb_string_view.tcc

The local modifications are done in the following patch in order to make
it easier to review them.

gdb/ChangeLog:

* common/gdb_string_view.h: New file.
* common/gdb_string_view.tcc: New file.

Update ax_cv_cxx_compile_cxx.m4

This file provides the AX_CXX_COMPILE_STDCXX macro. In the context of
the following patch, I wanted to build and test GDB in c++17 mode. The
version of the macro we have in the repo does not support detecting
c++17 compilers, but the upstream version has been updated to do so.

Since we have local modifications to the file, I had to reconcile our
modifications and the updated upstream version (which was relatively
straightforward).

gdb/ChangeLog:

* ax_cxx_compile_stdcxx.m4: Sync with upstream.
* configure: Re-generate.

Regenerate some files

The gold change is to pick up HJ's PR22318 AC_PLUGINS update. The
ld change is to correct a file I generated from a modified tree.

gold/
* configure: Regenerate.
ld/
* po/BLD-POTFILES.in: Regenerate.

Apply "Convert observers to C++" edit to gdbarch.sh

Regenerating gdbarch.c results in:

--- gdbarch.c 2018-03-26 23:18:52.905548891 +0100
+++ new-gdbarch.c 2018-04-09 15:32:30.006712207 +0100
@@ -44,7 +44,7 @@
#include "reggroups.h"
#include "osabi.h"
#include "gdb_obstack.h"
-#include "observable.h"
+#include "observer.h"
#include "regcache.h"
#include "objfiles.h"
#include "auxv.h"
@@ -5457,7 +5457,7 @@
gdb_assert (new_gdbarch != NULL);
gdb_assert (new_gdbarch->initialized_p);
current_inferior ()->gdbarch = new_gdbarch;
- gdb::observers::architecture_changed.notify (new_gdbarch);
+ observer_notify_architecture_changed (new_gdbarch);
registers_changed ();
}


Clearly commit 76727919ceb5 ("Convert observers to C++") edited
gdbarch.c directly instead of gdbarch.sh. This fixes it.

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

* gdbarch.sh: Include "observable.h" instead of "observer.h".
(set_target_gdbarch): Call
gdb::observers::architecture_changed.notify instead of
observer_notify_architecture_changed.

binutils/testsuite: Fix a crash with STN_UNDEF in relocation

Verify that `strip' completes successfully and a correct relocation
entry is copied for a relocation encountered with the STN_UNDEF symbol
index.

binutils/
* testsuite/binutils-all/strip-15.d: New test.
* testsuite/binutils-all/strip-15rel.s: New test source.
* testsuite/binutils-all/strip-15rela.s: New test source.
* testsuite/binutils-all/strip-15mips64.s: New test source.
* testsuite/binutils-all/objcopy.exp: Run the new test.