gdb: fix build errors in gdbsupport/thread-pool.h used with old gcc

When I build gdb with gcc 8.3, there exist the following build errors,
rename the typedef to task_t to fix them.

  CXX      thread-pool.o
In file included from /home/loongson/gdb.git/gdbsupport/thread-pool.cc:21:
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<void> gdb::thread_pool::post_task(std::function<void()>&&)’:
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:69:44: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local]
     std::packaged_task<void ()> task (std::move (func));
                                            ^~~~
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here
   typedef std::packaged_task<void ()> task;
                                       ^~~~
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<_Res> gdb::thread_pool::post_task(std::function<T()>&&)’:
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:80:41: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local]
     std::packaged_task<T ()> task (std::move (func));
                                         ^~~~
/home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here
   typedef std::packaged_task<void ()> task;
                                       ^~~~

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

[gdb/testsuite] Detect 'No MPX support'

On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
...
(gdb) run ^M
Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
No MPX support^M
...
and eventually into all sort of fails in this and other mpx test-cases.

Fix this by detecting the "No MPX support" message in have_mpx.

Tested on x86_64-linux with target boards unix and unix/-m32.

M68K: avoid quadratic slowdlow in label alignment check

Before the change tc-m68k maintained a list of seen labels.
Alignment check traversed label list to resolve symbol to label.
This caused quadratic slowdown as each symbol was checked against
each label. Worst affected files are the ones built with debugging
enabled as DWARF generates many labels.

The change embeds auxiliary label information right into symbol using
TC_SYMFIELD_TYPE.

Before the change test from PR 29058 did not finish in 10 minutes. After
the change it finishes in 2 seconds.

gas/ChangeLog:

PR 29058
* config/tc-m68k.h (TC_SYMFIELD_TYPE): define as m68k_tc_sy.
* config/tc-m68k.c (m68k_frob_label): Use TC_SYMFIELD_TYPE to
store label information.

ld:LoongArch: Fix glibc fail: tst-audit25a/b.

  bfd/

  * elfnn-loongarch.c: Add new func elf_loongarch64_hash_symbol.

Automatic date update in version.in

gdb: add ATTRIBUTE_PRINTF to complaint_interceptor::issue_complaint

Fix this error when building with clang++-14:

      CXX    complaints.o
    /home/smarchi/src/binutils-gdb/gdb/complaints.c:130:65: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
      g_complaint_interceptor->m_complaints.insert (string_vprintf (fmt, args));
                                                                    ^~~

Change-Id: I0ef11f970510eb8638d1651fa0d5eeecd6a9d31a

gdb: fix clang build failure in msymbol_is_mips

Building with clang++-14, I see:

      CXX    mips-tdep.o
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
      return !(MSYMBOL_TARGET_FLAG_MIPS16 (msym)
              ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
            (sym)->target_flag_1 ()
            ^
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: note: cast one or both operands to int to silence this warning
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
            (sym)->target_flag_1 ()
            ^

That's since commit e165fcef1e7 ("gdb: remove MSYMBOL_TARGET_FLAG_{1,2}
macros").  Fix this by using the boolean || rather than the bitwise |,
since the new methods return bool values.  No change in behavior
expected.

Change-Id: Ia82664135aa25db64c29c92f5c1141859d345bf7

binutils: enable PE on 32bit haiku build

* config.bfd (x86-haiku): Add i386_pei_vec as a selectable format.

Make intrusive_list_node's next/prev private

Tromey noticed that intrusive_list_node leaves its data members
public, which seems sub-optimal.

This commit makes intrusive_list_node's data fields private.
intrusive_list_iterator, intrusive_list_reverse_iterator, and
intrusive_list do need to access the fields, so they are made friends.

Change-Id: Ia8b306b40344cc218d423c8dfb8355207a612ac5

Tidy gdb.base/parse_number.exp

Now that Ada is able to parse & print 0xffffffffffffffff (2^64-1) in
hex, move it to the else branch like most other languages.

Change-Id: Ib305f6bb2b6b230a1190ea783b245b865821094c

ubsan: member access within null pointer of union

Add some nonsense to cover "undefined behaviour".

* ldlang.c (section_for_dot): Avoid UB.

Automatic date update in version.in

Fix bug in Ada number lexing

On irc, Pedro pointed out that Ada couldn't properly handle
0xffffffffffffffff.  This used to work, but is a regression due to
some patches I wrote in the Ada lexer.  This patch fixes the bug.

gdb: fix "passing NULL to memcpy" UBsan error in dwarf2/cooked-index.c

Reading a simple file compiled with :

    $ gcc -DONE=1 -gdwarf-4 -g3  test.c
    $ gcc --version
    gcc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0

I get:

    Reading symbols from /tmp/cwd/a.out...
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:332:11: runtime error: null pointer passed as argument 2, which is declared to never be null

It looks like even if the size is 0 (the size of the `entries` vector is
0), we shouldn't be passing a NULL pointer to memcpy.  And
`entries.data ()` returns NULL.

Fix that by using std::vector::insert to insert the items of entries
into m_entries.  I haven't checked, but it should essentially compile
down to a memcpy, since the vector elements are trivially copyiable.

Change-Id: I75f1c901e9b522e42e89eb5936e2c70d68eb21e5

gdb: change subfile::line_vector to an std::vector

Change this field to an std::vector to facilitate memory management.
Since the linetable_entry array is copied into the symtab resulting from
the subfile, it is possible to change it without changing how symtab
stores the linetable entries (which would be a much larger change).

There is a small change in buildsym_compunit::record_line to avoid
accessing a now invalid linetable_entry.  Before this patch, we keep a
pointer to the last linetable entry, pop it from the vector, and then
read last->line.  It works with the manually-maintained array, but since
we now use std::vector::pop_back, I am afraid that it could be flagged
as an invalid access by the various static / dynamic analysis tools to
access the linetable_entry object after popping it from the vector.
Instead, record just the line number in an optional and use it.

There are substantial changes in xcoffread.c that simplify the code, but
I can't test them.  I was hesitant to do this change because of that,
but I decided to send it anyway.  I don't think that an almost dead
platform should hold back improving the code in the common parts of GDB.

The changes in xcoffread.c are:

 - Make arrange_linetable "arrange" the linetable passed as a parameter,
   instead of returning possibly a new one, possibly the same one.
 - In the "Process main file's line numbers.", I'm not too sure what
   happens.  We get the lintable from "main_subfile", "arrange" it, but
   then assign the result to the current subfile, obtained with
   get_current_subfile.  I assume that the current subfile is also the
   main one, so now I just call arrange_linetable on the main subfile's
   line table.
 - Remove that weird "Useless if!!!" FIXME comment.  It's been there
   forever, but the "if" is still there, so I guess the "if" can stay
   there.

Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80

gdb: use std::vector for temporary linetable_entry array in arrange_linetable

Reduce manual memory management and make the code a bit easier to read.
This helps me a bit in the following patch.

I don't have a way to test this, it's best-effort.

Change-Id: I64af9cd756311deabc6cd95e701dfb21234a40a5

gdb: change subfile::name and buildsym_compunit::m_comp_dir to strings

Change subfile::name to be a string, for easier memory management.
Change buildsym_compunit::m_comp_dir as well, since we move one in to
the other at some point in patch_subfile_names, so it's easier to do
both at the same time.  There are various NULL checks for both fields
currently, replace them with empty checks, I think it ends up
equivalent.

I can't test the change in xcoffread.c, it's best-effort.

Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016

gdb: allocate subfile with new

Allocate struct subfile with new, initialize its fields instead of
memset-ing it to 0.  Use a unique_ptr for the window after a subfile has
been allocated but before it is linked in the buildsym_compunit's list
of subfile (and therefore owned by the buildsym_compunit.

I can't test the change in xcoffread.c, it's best-effort.  I couldn't
find where subfiles are freed in that file, I assume they were
intentionally (or not) leaked.

Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24

gdb: use decltype instead of typeof in dwarf2/read.c

When building with -std=c++11, I get:

  CXX    dwarf2/read.o
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function â€˜void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before â€˜typeof’
 7130 |     using iter_type = typeof (per_bfd->all_comp_units.begin ());
      |                       ^~~~~~

This is because typeof is a GNU extension.  Use C++'s decltype keyword
instead.

Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14

gdbsupport: use result_of_t instead of result_of in parallel-for.h

When building with -std=c++11, I get:

In file included from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22:                                                                             /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:134:10: error: â€˜result_of_t’ is not a member of â€˜std’; did you mean â€˜result_of’?
  134 |     std::result_of_t<RangeFunction (RandomIt, RandomIt)>
      |          ^~~~~~~~~~~
      |          result_of

This is because result_of_t has been introduced in C++14.  Use the
equivalent result_of<...>::type instead.

result_of and result_of_t have been removed in C++20 though, so I think
we'll need some patches eventually to make the code use invoke_result
instead, depending on the C++ version.

Change-Id: I4817f361c0ebcdd4b32976898fc368bb302b61b9

Remove dwarf2_per_cu_data::v

Now that the psymtab reader has been removed, the
dwarf2_per_cu_data::v union is no longer needed.  Instead, we can
simply move the members from dwarf2_per_cu_quick_data into
dwarf2_per_cu_data and remove the "quick" object entirely.

Delete DWARF psymtab code

This removes the DWARF psymtab reader.

Enable the new DWARF indexer

This patch finally enables the new indexer.  It is left until this
point in the series to avoid any regressions; in particular, it has to
come after the changes to the DWARF index writer to avoid this
problem.

However, if you experiment with the series, this patch can be moved
anywhere from the patch to wire in the new reader to this point.
Moving this patch around is how I got separate numbers for the
parallelization and background finalization patches.

In the ongoing performance example, this reduces the time from the
baseline of 1.598869 to 0.903534.

Adapt .debug_names writer to new DWARF scanner

This updates the .debug_names writer to work with the new DWARF
scanner.

Adapt .gdb_index writer to new DWARF scanner

This updates the .gdb_index writer to work with the new DWARF scanner.
The .debug_names writer is deferred to another patch, to make review
simpler.

This introduces a small hack to psyms_seen_size, but is
inconsequential because this function will be deleted in a subsequent
patch.

Genericize addrmap handling in the DWARF index writer

This updates the DWARF index writing code to make the addrmap-writing
a bit more generic.  Now, it can handle multiple maps, and it can work
using the maps generated by the new indexer.

Note that the new addrmap_index_data::using_index field will be
deleted in a future patch, when the rest of the DWARF psymtab code is
removed.

Change parameters to write_address_map

To support the removal of partial symtabs from the DWARF index writer,
this makes a small change to have write_address_map accept the address
map as a parameter, rather than assuming it always comes from the
per-BFD object.

Change the key type in psym_index_map

In order to change the DWARF index writer to avoid partial symtabs,
this patch changes the key type in psym_index_map (and renames that
type as well).  Using the dwarf2_per_cu_data as the key makes it
simpler to reuse this code with the new indexer.

Rename write_psymtabs_to_index

We'll be removing all the psymtab code from the DWARF reader.  As a
preparatory step, this renames write_psymtabs_to_index to avoid the
"psymtab" name.

"Finalize" the DWARF index in the background

After scanning the CUs, the DWARF indexer merges all the data into a
single vector, canonicalizing C++ names as it proceeds.  While not
necessarily single-threaded, this process is currently done in just
one thread, to keep memory costs lower.

However, this work is all done without reference to any data outside
of the indexes.  This patch improves the apparent performance of GDB
by moving it to the background.  All uses of the index are then made
to wait for this process to complete.

In our ongoing example, this reduces the scanning time on gdb itself
to 0.173937 (wall).  Recall that before this patch, the time was
0.668923; and psymbol reader does this in 1.598869.  That is, at the
end of this series, we see about a 10x speedup.

Parallelize DWARF indexing

This parallelizes the new DWARF indexer.  The indexer's storage was
designed so that each storage object and each indexer is fully
independent.  This setup makes it simple to scan different CUs
independently.

This patch creates a new cooked index storage object per thread, and
then scans a subset of all the CUs in each such thread, using gdb's
existing thread pool.

In the ongoing "gdb gdb" example, this patch reduces the wall time
down to 0.668923, from 0.903534.  (Note that the 0.903534 is the time
for the new index -- that is, when the "enable the new index" patch is
rebased to before this one.  However, in the final series, that patch
appears toward the end.  Hopefully this isn't too confusing.)

Pre-read DWARF section data

Because BFD is not thread-safe, we need to be sure that any section
data that is needed is read before trying to do any DWARF indexing in
the background.

This patch takes a simple approach to this -- it pre-reads the
"info"-related sections.  This is done for the main file, but also any
auxiliary files as well, such as the DWO file.

This patch could be perhaps enhanced by removing some now-redundant
calls to dwarf2_section_info::read.

Introduce thread-safe handling for complaints

This introduces a new class that can be used to make the "complaint"
code thread-safe.  Instantiating the class installs a new handler that
collects complaints, and then prints them all when the object is
destroyed.

This approach requires some locks.  I couldn't think of a better way
to handle this, though, because the I/O system is not thread-safe.

It seemed to me that only GDB developers are likely to enable
complaints, and because the complaint macro handle this case already
(before any locks are required), I reasoned that any performance
degradation that would result here would be fine.

As an aside about complaints -- are they useful at all?  I just ignore
them, myself, since mostly they seem to indicate compiler problems
that can't be solved in the GDB world anyway.  I'd personally prefer
them to be in a separate tool, like a hypothetical 'dwarflint'.

Wire in the new DWARF indexer

This wires the new DWARF indexer into the existing reader code.  That
is, this patch makes the modification necessary to enable the new
indexer.  It is not actually enabled by this patch -- that will be
done later.

I did a bit of performance testing for this patch and a few others.  I
copied my built gdb to /tmp, so that each test would be done on the
same executable.  Then, each time, I did:

    $ ./gdb -nx
    (gdb) maint time 1
    (gdb) file /tmp/gdb

This patch is the baseline and on one machine came in at 1.598869 wall
time.

Implement quick_symbol_functions for cooked DWARF index

This implements quick_symbol_functions for the cooked DWARF index.
This is the code that interfaces between the new index and the rest of
gdb.  Cooked indexes still aren't created by anything.

For the most part this is straightforward.  It shares some concepts
with the existing DWARF indices.  However, because names are stored
pre-split in the cooked index, name lookup here is necessarily
different; see expand_symtabs_matching for the gory details.

The new DWARF indexer

This patch adds the code to index DWARF.  This is just the scanner; it
reads the DWARF and constructs the index, but nothing calls it yet.

The indexer is split into two parts: a storage object and an indexer
object.  This is done to support the parallelization of this code -- a
future patch will create a single storage object per thread.

Introduce the new DWARF index class

This patch introduces the new DWARF index class.  It is called
"cooked" to contrast against a "raw" index, which is mapped from disk
without extra effort.

Nothing constructs a cooked index yet.  The essential idea here is
that index entries are created via the "add" method; then when all the
entries have been read, they are "finalize"d -- name canonicalization
is performed and the entries are added to a sorted vector.

Entries use the DWARF name (DW_AT_name) or linkage name, not the full
name as is done for partial symbols.

These two facets -- the short name and the deferred canonicalization
-- help improve the performance of this approach.  This will become
clear in later patches, when parallelization is added.

Some special code is needed for Ada, because GNAT only emits mangled
("encoded", in the Ada lingo) names, and so we reconstruct the
hierarchical structure after the fact.  This is also done in the
finalization phase.

One other aspect worth noting is that the way the "main" function is
found is different in the new code.  Currently gdb will notice
DW_AT_main_subprogram, but won't recognize "main" during reading --
this is done later, via explicit symbol lookup.  This is done
differently in the new code so that finalization can be done in the
background without then requiring a synchronization to look up the
symbol.

Update skip_one_die for new abbrev properties

This updates skip_one_die to speed it up in the cases where either
sibling_offset or size_if_constant are set.

Statically examine abbrev properties

The new DIE scanner works more or less along the lines indicated by
the text for the .debug_names section, disregarding the bugs in the
specification.

While working on this, I noticed that whether a DIE is interesting is
a static property of the DIE's abbrev.  It also turns out that many
abbrevs imply a static size for the DIE data, and additionally that
for many abbrevs, the sibling offset is stored at a constant offset
from the start of the DIE.

This patch changes the abbrev reader to analyze each abbrev and stash
the results on the abbrev.  These combine to speed up the new indexer.
If the "interesting" flag is false, GDB knows to skip the DIE
immediately.  If the sibling offset is statically known, skipping can
be done without reading any attributes; and in some other cases, the
DIE can be skipped using simple arithmetic.

Introduce DWARF abbrev cache

The replacement for the DWARF psymbol reader works in a somewhat
different way.  The current reader reads and stores all the DIEs that
might be interesting.  Then, if it is missing a DIE, it re-scans the
CU and reads them all.  This approach is used for both intra- and
inter-CU references.

I instrumented the partial DIE hash to see how frequently it was used:

    [  0] -> 1538165
    [  1] ->    4912
    [  2] ->   96102
    [  3] ->     175
    [  4] ->     244

That is, most DIEs are never used, and some are looked up twice -- but
this is just an artifact of the implementation of
partial_die_info::fixup, which may do two lookups.

Based on this, the new implementation doesn't try to store any DIEs,
but instead just re-scans them on demand.  In order to do this,
though, it is convenient to have a cache of DWARF abbrevs.  This way,
if a second CU is needed to resolve an inter-CU reference, the abbrevs
for that CU need only be computed a single time.

Add "fullname" handling to file_and_directory

This changes the file_and_directory object to be able to compute and
cache the "fullname" in the same way that is done by other code, like
the psymtab reader.

Specialize std::hash for gdb_exception

This adds a std::hash specialization for gdb_exception.  This lets us
store these objects in a hash table, which is used later in this
series to de-duplicate the exception output from multiple threads.

Return vector of results from parallel_for_each

This changes gdb::parallel_for_each to return a vector of the results.
However, if the passed-in function returns void, the return type
remains 'void'.  This functionality is used later, to parallelize the
new indexer.

Add batching parameter to parallel_for_each

parallel_for_each currently requires each thread to process at least
10 elements.  However, when indexing, it's fine for a thread to handle
just a single CU.  This patch parameterizes this, and updates the one
user.

Refactor build_type_psymtabs_reader

The new DWARF scanner needs to save the entire cutu_reader object, not
just parts of it.  In order to make this possible, this patch
refactors build_type_psymtabs_reader.  This change is done separately
because it is easy to review in isolation and it helps make the later
patches smaller.

Add new overload of dwarf5_djb_hash

This adds a new overload of dwarf5_djb_hash.  This is used in
subsequent patches.

Add name splitting

The new DWARF index code works by keeping names pre-split.  That is,
rather than storing a symbol name like "a::b::c", the names "a", "b",
and "c" will be stored separately.

This patch introduces some helper code to split a full name into its
components.

Let skip_one_die not skip children

This patch adds an option to skip_one_die that causes it not to skip
child DIEs.  This is needed in the new scanner.

Allow ada_decode not to decode operators

The new DWARF scanner records names as they appear in DWARF.  However,
because Ada is unusual, it also decodes the Ada names to synthesize
package components for them.  In order for this to work out properly,
gdb also needs a mode where ada_decode can be instructed not to decode
Ada operator names.  That is what this patch implements.

Refactor dwarf2_get_pc_bounds

This changes dwarf2_get_pc_bounds so that it does not directly access
a psymtab or psymtabs_addrmap.  Instead, both the addrmap and the
desired payload are passed as parameters.  This makes it suitable to
be used by the new indexer.

Add dwarf2_per_cu_data::addresses_seen

This adds a new member to dwarf2_per_cu_data that indicates whether
addresses have been seen for this CU.  This is then set by the
.debug_aranges reader.  The idea here is to detect when a CU does not
have address information, so that the new indexer will know to do
extra scanning in that case.

Fix latent bug in read_addrmap_from_aranges

Tom de Vries found a failure that we tracked down to a latent bug in
read_addrmap_from_aranges (previously create_addrmap_from_aranges).
The bug is that this code can erroneously reject .debug_aranges when
dwz is in use, due to CUs at duplicate offsets.  Because aranges can't
refer to a CU coming from the dwz file, the fix is to simply skip such
CUs in the loop.

Split create_addrmap_from_aranges

This patch splits create_addrmap_from_aranges into a wrapper function
and a worker function.  The worker function is then used in a later
patch.

Allow thread-pool.h to work without threads

thread-pool.h requires CXX_STD_THREAD in order to even be included.
However, there's no deep reason for this, and during review we found
that one patch in the new DWARF indexer series unconditionally
requires the thread pool.

Because the thread pool already allows a task to be run in the calling
thread (for example if it is configured to have no threads in the
pool), it seemed straightforward to make this code ok to use when host
threads aren't available at all.

This patch implements this idea.  I built it on a thread-less host
(mingw, before my recent configure patch) and verified that the result
builds.

After the thread-pool change, parallel-for.h no longer needs any
CXX_STD_THREAD checks at all, so this patch removes these as well.

Rebase the zlib sources to the 1.2.12 release

[gdb/testsuite] Fix gdb.base/stap-probe.exp with read1

When running test-case gdb.base/stap-probe.exp with make target check-read1, I
run into this and similar:
...
FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
  info probes stap (timeout)
...

Fix this by using gdb_test_lines instead of gdb_test.

Tested on x86_64-linux.

Add C++ "save gdb-index" test

I found a bug in the new DWARF reader series, related to the handling
of enumerator names.  This bug caused a crash, so this patch adds a
regression test for this particular case.  I'm checking this in.

Remove "Ada Settings" node from the manual

A while back, I sent a patch to unify the Ada varsize-limit setting
with the more generic max-value-size:

https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html

However, it turns out I somehow neglected to send part of the patch.
Internally, I also removed the "Ada Settings" node from the manual, as
it only documents the obsolete setting.

This patch removes this text.

Require GNAT debug info for some Ada tests

A few Ada tests require some debug info in the GNAT runtime.  When run
without this info, these tests can't pass.  This patch changes these
tests to detect this situation and stop with "untested".

Stop strip from removing debuglink sections.

PR 28992
* objcopy.c (is_strip_section_1): Do not delete debuglink sections
when stripping debug information.

gas: new_logical_line{,_flags}() can return "void"

With the sole user of the return value gone, convert the return type to
void. This in turn allows simplifying another construct, by moving it
slightly later in the function.

gas: drop .appfile and .appline

These were used originally to represent "# <line> <file>" constructs
inserted by (typically) compilers when pre-processing. Quite some time
ago they were replaced by .linefile though. Since the original
directives were never documented, we ought to be able to remove support
for them. As a result in a number of case function parameter aren't used
anymore and can hence be dropped.

gas: further adjust file/line handling for .macro

Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
and alike blocks"), while dealing okay with actual assembly source files
not using .file/.line and alike outside but not inside of .macro, has
undue effects when the logical file/line pair was already overridden:
Line numbers would continuously increment while processing the expanded
macro, while the goal of the PR gas/16908 workaround is to keep the
expansion associated with the line invoking the macro. However, as soon
as enough state was overridden _inside_ the macro to cause as_where() to
no longer fall back top as_where_physical(), honor this by resuming the
bumping of the logical line number.

Note that from_sb_is_expansion's initializer was 1 for an unknown
reason. While renaming the variable and changing its type, also change
the initializer to "expanding_none", which would have been "0" in the
original code. Originally the initializer value itself wasn't ever used
anyway (requiring sb_index != -1), as it necessarily had changed in
input_scrub_include_sb() alongside setting sb_index to other than -1.

Strictly speaking input_scrub_insert_line() perhaps shouldn't use
expanding_none, yet none of the other enumerators fit there either. And
then strictly speaking that function probably shouldn't exist in the
first place. It's used only by tic54x.

gas: further adjust file/line handling for .irp and alike

Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
and alike blocks"), while dealing okay with actual assembly source files
not using .file/.line and alike outside but not inside of .irp et al,
has undue effects when the logical file/line pair was already
overridden: Line numbers would continuously increment upon every
iteration, thus potentially getting far off. Furthermore it left it to
the user to actually insert .file/.line inside such constructs. Note
though that before aforementioned change things weren't pretty either:
Diagnostics (and debug info) would be associated with the directive
terminating the iteration construct, rather than with the actual lines.

Handle this automatically by simply latching the present line and then
re-instating coordinates first thing on every iteration; note that the
file can't change from what was previously pushed on the scrubber's
state stack, and hence can be taken from there by using a new flavor of
.linefile (which is far better memory-footprint-wise than recording the
full path in the inserted directive). (This then leaves undisturbed any
file/line control occurring in the body of the construct, as these will
only be seen and processed afterwards.)

x86: make {disp16} work similarly to {disp32}

In a few places {disp32} was handled specially when really {disp16}
wants handling just the same.

gprofng doesn't build with gcc 5.5

gprofng/ChangeLog
2022-04-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29026
* configure.ac: Check version of bison.
* src/Makefile.am (QLParser.yy): Run bison
* src/QLParser.yy: Adapted for bison 3.04 or later.
* src/DbeSession.cc: make some params const.
* src/DbeSession.h: Likewise.
* configure: Regenerate.
* Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/QLParser.tab.cc: Deleted.
* src/QLParser.tab.hh: Deleted.
* doc/Makefile.in: Regenerate.
* gp-display-html/Makefile.in: Regenerate.
* libcollector/configure: Regenerate.

Automatic date update in version.in

i386-fbsd-nat: Remove two unused variables.

Earlier versions of the change in
1285ce8629b37f800bf21731ee7c7a8b1b8d0233 used this variable, but not
the final version that landed.

gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macros

Replace with equivalent getter/setter macros.

Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2

gdb: remove minimal symbol size macros

Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them
with equivalent methods.

Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538

gdb: remove MSYMBOL_TYPE macro

Add a getter and a setter for a minimal symbol's type.  Remove the
corresponding macro and adjust all callers.

Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d

gdb: remove symbol value macros

Remove all macros related to getting and setting some symbol value:

    #define SYMBOL_VALUE(symbol)           (symbol)->value.ivalue
    #define SYMBOL_VALUE_ADDRESS(symbol)                         \
    #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value)    \
    #define SYMBOL_VALUE_BYTES(symbol)     (symbol)->value.bytes
    #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block
    #define SYMBOL_BLOCK_VALUE(symbol)     (symbol)->value.block
    #define SYMBOL_VALUE_CHAIN(symbol)     (symbol)->value.chain
    #define MSYMBOL_VALUE(symbol)          (symbol)->value.ivalue
    #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
    #define MSYMBOL_VALUE_ADDRESS(objfile, symbol)                         \
    #define BMSYMBOL_VALUE_ADDRESS(symbol) \
    #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value)   \
    #define MSYMBOL_VALUE_BYTES(symbol)    (symbol)->value.bytes
    #define MSYMBOL_BLOCK_VALUE(symbol)    (symbol)->value.block

Replace them with equivalent methods on the appropriate objects.

Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50

gdb/doc: add section about Fortran intrinsic functions and types

The earlier version of this document had no sections about the
available Fortran intrinsic functions or the Fortran builtin types.

I added two sections 'Fortran intrinsics' and 'Fortran types' to
document the available Fortran language features.  The subsection
'Fortran Defaults' has been integrated into the Fortran subsection.

gdb/fortran/testsuite: add complex from integers test

When working on the files I noted that there was no actual test for a
COMPLEX built from two INTEGERS.  I added that now for completion.

gdb/fortran: rewrite intrinsic handling and add some missing overloads

The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept
(some only with Fortran 2003) the optional parameter KIND.  This
parameter determines the kind of the associated return value.  So far,
implementation of this kind parameter has been missing in GDB.
Additionally, the one argument overload for the CMPLX intrinsic function
was not yet available.

This patch adds overloads for all above mentioned functions to the
Fortran intrinsics handling in GDB.

It re-writes the intrinsic function handling section to use the helper
methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic.
These methods define the action taken when a Fortran intrinsic function
is called with a certain amount of arguments (1/2/3). The helper methods
fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents
to the existing wrap and wrap2 methods.

After adding more overloads to the intrinsics handling, some of the
operation names were no longer accurate.  E.g. UNOP_FORTRAN_CEILING
has been renamed to FORTRAN_CEILING as it is no longer a purely unary
intrinsic function.  This patch also introduces intrinsic functions with
one, two, or three arguments to the Fortran parser and the
UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.

gdb/fortran: rename f77_keywords to f_keywords

Rename f77_keywords to f_keywords since some of the introduced keywords
in the array are f90 only.

gdb/fortran: Change GDB print for fortran default types

Currently, when asking GDB to print the type of a Fortran default type
such as INTEGER or REAL, GDB will return the default name of that type,
e.g. "integer"/"real":

   (gdb) ptype integer
   type = integer
   (gdb) ptype real
   type = real

For LOGICAL and COMPLEX it would return the actual underlying types

   (gdb) ptype logical
   type = logical*4
   (gdb) ptype complex
   type = complex*4

Similarly, GDB would print the default integer type for the underlying
default type:

   (gdb) ptype integer*4
   type = integer
   (gdb) ptype real*4
   type = real
   (gdb) ptype logical
   type = logical*4
   (gdb) ptype complex*4
   type = complex*4

This is inconsistent and a bit confusing.  Both options somehow indicate
what the internal underlying type for the default type is - but I think
the logical/complex version is a bit clearer.

Consider again:

   (gdb) ptype integer
   type = integer

This indicates to a user that the type of "integer" is Fortran's default
integer type.  Without examining "ptype integer*4" I would expect, that
any variable declared integer in the actual code would also fit into a
GDB integer.  But, since we cannot adapt out internal types to the
compiler flags used at compile time of a debugged binary, this might be
wrong.  Consider debugging Fortran code compiled with GNU and e.g. the
"-fdefault-integer-8" flag.  In this case the gfortran default integer
would be integer*8 while GDB internally still would use a builtin_integer,
so an integer of the size of an integer*4 type.  On the other hand having
GDB print

   (gdb) ptype integer
   type = integer*4

makes this clearer.  I would still be tempted to fit a variable declared
integer in the code into a GDB integer - but at least ptype would
directly tell me what is going on.  Note, that when debugging a binary
compiled with "-fdefault-integer-8" a user will always see the actual
underlying type of any variable declared "integer" in the Fortran code.
So having the code

   program test
     integer :: a = 5
     print *, a ! breakpt
   end program test

will, when breaking at breakpt print

   (gdb) ptype var
   type = integer(kind=4)

or

   (gdb) ptype var
   type = integer(kind=8)

depending on the compiler flag.

This patch changes the outputs for the REAL and INTEGER default types to
actually print the internally used type over the default type name.

The new behavior for the above examples is:

   (gdb) ptype integer
   type = integer*4
   (gdb) ptype integer*4
   type = integer*4

Existing testcases have been adapted to reflect the new behavior.

gdb/fortran: clean-up Fortran intrinsic types

The currently implemented intrinsic type handling for Fortran missed some
tokens and their parsing.  While still not all Fortran type kinds are
implemented this patch at least makes the currently handled types
consistent.  As an example for what this patch does, consider the
intrinsic type INTEGER.  GDB implemented the handling of the
keywords "integer" and "integer_2" but missed "integer_4" and "integer_8"
even though their corresponding internal types were already available as
the Fortran builtin types builtin_integer and builtin_integer_s8.
Similar problems applied to LOGICAL, REAL, and COMPLEX.  This patch adds
all missing tokens and their parsing.  Whenever a section containing the
type handling was touched, it also was reordered to be in a more easy to
grasp order.  All INTEGER/REAL/LOGICAL/COMPLEX types were grouped
together and ordered ascending in their size making a missing one more
easy to spot.

Before this change GDB would print the following when tyring to use the
INTEGER keywords:

   (gdb) set language fortran
   (gdb) ptype integer*1
   unsupported kind 1 for type integer
   (gdb) ptype integer_1
   No symbol table is loaded.  Use the "file" command.
   (gdb) ptype integer*2
   type = integer*2
   (gdb) ptype integer_2
   type = integer*2
   (gdb) ptype integer*4
   type = integer
   (gdb) ptype integer_4
   No symbol table is loaded.  Use the "file" command.
   (gdb) ptype integer*8
   type = integer*8
   (gdb) ptype integer_8
   No symbol table is loaded.  Use the "file" command.
   (gdb) ptype integer
   type = integer

With this patch all keywords are available and the GDB prints:

   (gdb) set language fortran
   (gdb) ptype integer*1
   type = integer*1
   (gdb) ptype integer_1
   type = integer*1
   (gdb) ptype integer*2
   type = integer*2
   (gdb) ptype integer_2
   type = integer*2
   (gdb) ptype integer*4
   type = integer*4
   (gdb) ptype integer_4
   type = integer*4
   (gdb) ptype integer*8
   type = integer*8
   (gdb) ptype integer_8
   type = integer*8
   (gdb) ptype integer
   type = integer

The described changes have been applied to INTEGER, REAL, COMPLEX,
and LOGICAL. Existing testcases have been adapted to reflect the
new behavior.  Tests for formerly missing types have been added.

gdb/fortran: change default logical type to builtin_logical

According to the Fortran standard, logical is of the size of a
'single numeric storage unit' (just like real and integer). For
gfortran, flang and ifx/ifort this storage unit (or the default
logical type) is of size kind 4, actually occupying 4 bytes of
storage, and so the default type for logical expressions in
Fortran should probably also be Logical*4 and not Logical*2.  I
adapted GDB's behavior to be in line with
gfortran/ifort/ifx/flang.

gdb/fortran: reformat build_fortran_types in f-lang.c

Add a few newlines after the type definitions and remove some
unnecessary linebreaks.

gdb/fortran: fix complex type in Fortran builtin types

Before this patch things like

  (gdb) ptype complex*8
  complex*16
  (gdb) ptype complex*4
  complex*8

were possible in GDB, which seems confusing for a user.  The reason
is a mixup in the implementation of the Fortran COMPLEX type.  In
Fortran the "*X" after a type would normally (I don't think this
is language required) specify the type's size in memory.  For the
COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang)
specify not the size of the whole type but the size of the individual
two REALs used to form the COMPLEX.  Thus, a COMPLEX*4 will usually
consist of two REAL*4s.  Internally this type was represented by a
builtin_complex_s8 - but here I think the s8 actually meant the raw
size of the type.  This is confusing and I renamed the types (e.g.
builting_complex_s8 became builtin_complex_s4 according to its most
common useage) and their printed names to their language equivalent.
Additionally, I added the default COMPLEX type "COMPLEX" being the same
as a COMPLEX*4 (as is normally the case) and removed the latter.  I added
a few tests for this new behavior as well.

The new behavior is

  (gdb) ptype complex*8
  complex*8
  (gdb) ptype complex*4
  complex*4

gdb/f-lang: remove hidden ^L characters

gdb/f-lang: add Integer*1 to Fortran builtin types

Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.

[gdb/testsuite] Fix gdb.base/annota1.exp with pie

Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more
robust") we see this fail with target board unix/-fPIE/-pie:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...

The problem is that the commit makes the number and order of matched
annotations fixed, while between target boards unix and unix/-fPIE/-pie there
is a difference:
...
 \032\032post-prompt
 Starting program: outputs/gdb.base/annota1/annota1

+\032\032breakpoints-invalid
+
 \032\032starting

 \032\032frames-invalid
...

Fix this by optionally matching the additional annotation.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp for m32 pie

As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
target board unix/-m32/-fPIE/-pie, we run into:
...
Breakpoint 2, 0x56555540 in bar ()^M
(gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
  continue to breakpoint: foo \(1\)
next^M
Single stepping until exit from function bar,^M
which has no line number information.^M
0x56555587 in main ()^M
(gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
  next to foo (2)
...

The problem is that the bar breakpoint ends up at an unexpected location
because:
- the synthetic debug info is incomplete and doesn't provide line info
  for the prologue part of the function, so consequently gdb uses the i386
  port prologue skipper to get past the prologue
- the i386 port prologue skipper doesn't get past a get_pc_thunk call.

Work around this in the test-case by breaking on bar_label instead.

Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
unix/-m32/-fPIE/-pie.

Automatic date update in version.in

Automatic date update in version.in

Remove MSYMBOL_VALUE_CHAIN

I noticed that MSYMBOL_VALUE_CHAIN is unused, so this patch removes it.

Rearrange struct bfd_section a little

For better packing on 64-bit hosts.

* section.c (struct bfd_section): Move next and prev field earlier.
Move alignment_power later.
(BFD_FAKE_SECTION): Adjust to suit.
* bfd-in2.h: Regenerate.

Don't run pr27228 test for hppa

As the comment says, hppa doesn't support use of BFD_RELOC_* in
.reloc directives.  Using xfail can result in a spurious XPASS result
as BFD_RELOC values change.

* testsuite/gas/elf/pr27228.d: Change xfail to notarget for hppa.

Correct nds32 readelf reloc numbers

* readelf.c (is_32bit_abs_reloc, is_16bit_abs_reloc): Comment fixes.
(is_none_reloc): Correct nds32 reloc numbers.

Automatic date update in version.in

gas: Port "copy st_size only if unset" to aarch64 and riscv

And disable the new test gas/elf/size.s for alpha which uses its own
.set, for hppa*-*-hpux* which does not allow .size before declaration.

gprofng: fprintf_styled_func not inizialized for disassembler

gprofng/ChangeLog
2022-04-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* libcollector/unwind.c: inizialize fprintf_styled_func.
* src/Disasm.cc: Likewise.

gprofng: zlib handling

gprofng/ChangeLog
2022-04-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* configure.ac: Add AM_ZLIB.
* src/Makefile.am: Add $(ZLIBINC) and $(ZLIB).
* gprofng/src/DbeSession.h: Likewise.
* configure: Regenerate.
* Makefile.in: Regenerate.
* doc/Makefile.in: Regenerate.
* gp-display-html/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.

gdb: Avoid undefined shifts, fix Go shifts

I noticed that a build of GDB with GCC + --enable-ubsan, testing
against GDBserver showed this GDB crash:

  (gdb) PASS: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: advance to trace begin
  tstart
  ../../src/gdb/valarith.c:1365:15: runtime error: left shift of 48320975398096333 by 46 places cannot be represented in type 'long int'
  ERROR: GDB process no longer exists
  GDB process exited with wait status 269549 exp9 0 1
  UNRESOLVED: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: start trace experiment

The problem is that, "0x00abababcdcdcdcd << 46" is an undefined signed
left shift, because the result is not representable in the type of the
lhs, which is signed.  This actually became defined in C++20, and if
you compile with "g++ -std=c++20 -Wall", you'll see that GCC no longer
warns about it, while it warns if you specify prior language versions.

While at it, there are a couple other situations that are undefined
(and are still undefined in C++20) and result in GDB dying: shifting
by a negative ammount, or by >= than the bit size of the promoted lhs.
For the latter, GDB shifts using (U)LONGEST internally, so you have to
shift by >= 64 bits to see it:

 $ gdb --batch -q -ex "p 1 << -1"
 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent -1 is negative
 $ # gdb exited

 $ gdb --batch -q -ex "p 1 << 64"
 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
 $ # gdb exited

Also, right shifting a negative value is implementation-defined
(before C++20, after which it is defined).  For this, I chose to
change nothing in GDB other than adding tests, as I don't really know
whether we need to do anything.  AFAIK, most implementations do an
arithmetic right shift, and it may be we don't support any host or
target that behaves differently.  Plus, this becomes defined in C++20
exactly as arithmetic right shift.

Compilers don't error out on such shifts, at best they warn, so I
think GDB should just continue doing the shifts anyhow too.

Thus:

- Adjust scalar_binop to avoid the undefined paths, either by adding
  explicit result paths, or by casting the lhs of the left shift to
  unsigned, as appropriate.

  For the shifts by a too-large count, I made the result be what you'd
  get if you split the large count in a series of smaller shifts.
  Thus:

     Left shift, positive or negative lhs:

       V << 64
 =>  V << 16 << 16 << 16 << 16
   => 0

     Right shift, positive lhs:

       Vpos >> 64
 =>  Vpos >> 16 >> 16 >> 16 >> 16
   => 0

     Right shift, negative lhs:

       Vneg >> 64
 =>  Vneg >> 16 >> 16 >> 16 >> 16
   => -1

  This is actually Go's semantics (the compiler really emits
  instructions to make it so that you get 0 or -1 if you have a
  too-large shift).  So for that language GDB does the shift and
  nothing else.  For other C-like languages where such a shift is
  undefined, GDB warns in addition to performing the shift.

  For shift by a negative count, for Go, this is a hard error.  For
  other languages, since their compilers only warn, I made GDB warn
  too.  The semantics I chose (we're free to pick them since this is
  undefined behavior) is as-if you had shifted by the count cast to
  unsigned, thus as if you had shifted by a too-large count, thus the
  same as the previous scenario illustrated above.

  Examples:

    (gdb) set language go
    (gdb) p 1 << 100
    $1 = 0
    (gdb) p -1 << 100
    $2 = 0
    (gdb) p 1 >> 100
    $3 = 0
    (gdb) p -1 >> 100
    $4 = -1
    (gdb) p -2 >> 100
    $5 = -1
    (gdb) p 1 << -1
    left shift count is negative

    (gdb) set language c
    (gdb) p -2 >> 100
    warning: right shift count >= width of type
    $6 = -1
    (gdb) p -2 << 100
    warning: left shift count >= width of type
    $7 = 0
    (gdb) p 1 << -1
    warning: left shift count is negative
    $8 = 0
    (gdb) p -1 >> -1
    warning: right shift count is negative
    $9 = -1

- The warnings' texts are the same as what GCC prints.

- Add comprehensive tests in a new gdb.base/bitshift.exp testcase, so
  that we exercise all these scenarios.

Change-Id: I8bcd5fa02de3114b7ababc03e65702d86ec8d45d

Fix undefined behavior in the Fortran, Go and Pascal number parsers

This commit ports these two fixes to the C parser:

  commit ebf13736b42af47c9907b5157c8e80c78dbe00e1
  CommitDate: Thu Sep 4 21:46:28 2014 +0100

      parse_number("0") reads uninitialized memory

  commit 20562150d8a894bc91657c843ee88c508188e32e
  CommitDate: Wed Oct 3 15:19:06 2018 -0600

      Avoid undefined behavior in parse_number

... to the Fortran, Go, and Fortran number parsers, fixing the same
problems there.

Also add a new testcase that exercises printing 0xffffffffffffffff
(max 64-bit) in all languages, which crashes a GDB built with UBsan
without the fix.

I moved get_set_option_choices out of all-architectures.exp.tcl to
common code to be able to extract all the supported languages.  I did
a tweak to it to generalize it a bit -- you now have to pass down the
"set" part of the command as well.  This is so that the proc can be
used with "maintenance set" commands as well in future.

Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a

Debug info for function in Windows PE binary on wrong instruction

PR 29038
* coffgen.c (coff_find_nearest_line_with_names): Fix typo
retrieving saved bias.

Pass PKG_CONFIG_PATH down from top-level Makefile

[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]

I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config.  If I just set it during
configure:

    $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure --with-debuginfod
    $ make

or

    $ ./configure --with-debuginfod PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
    $ make

Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
configure.  When running make (which runs gdb's and binutils'
configure), PKG_CONFIG_PATH is not set, which results in their configure
script not finding the library:

    checking for libdebuginfod >= 0.179... no
    configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable."

Change the top-level configure/Makefile system to capture the value
passed when configuring the top-level and pass it down to
subdirectories (similar to CFLAGS, LDFLAGS, etc).

I don't know much about the top-level build system, so I really don't
know if I did this correctly.  The changes are:

 - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
   @PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
   in config files (i.e. Makefile)
 - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
   to @PKG_CONFIG_PATH@
 - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
   variables set when running the sub-configures

I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
I don't think it's needed.  AFAIU, this defines the flags to pass down
when calling "make" in subdirectories.  We only need PKG_CONFIG_PATH to
be passed down during configure.  After that, it's captured in
gdb/config.status, so even if a "make" causes a re-configure later
(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
value will be remembered.

ChangeLog:

* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
* configure: Re-generate.
* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
(PKG_CONFIG_PATH): New.
* Makefile.in: Re-generate.

Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf

gdb/testsuite: use nopie in gdb.dwarf2/dw2-inline-param.exp

I see this failure:

    (gdb) run ^M
    Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
    Warning:^M
    Cannot insert breakpoint 1.^M
    Cannot access memory at address 0x113b^M
    ^M
    (gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b

The test loads the binary in GDB, grabs the address of a symbol, strips
the binary, reloads it in GDB, runs the program, and then tries to place
a breakpoint at that address.  The problem is that the binary is built
as position independent, so the address GDB grabs in the first place
isn't where the code ends up after running.

Fix this by linking the binary as non-position-independent.  The
alternative would be to compute the relocated address where to place the
breakpoint, but that's not very straightforward, unfortunately.

I was confused for a while, I was trying to load the binary in GDB
manually to get the symbol address, but GDB was telling me the symbol
could not be found.  Meanwhile, it clearly worked in gdb.log.  The thing
is that GDB strips the binary in-place, so we don't have access to the
intermediary binary with symbols.  Change the test to output the
stripped binary to a separate file instead.

Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba