gdb/testsuite: make gdb.dwarf2/dw2-empty-inline-ranges.exp work when ASLR can't be...

gdb/testsuite: make gdb.dwarf2/dw2-empty-inline-ranges.exp work when ASLR can't be disabled

A colleague that goes by the name "Luis Machado" reported a failure when
running gdb.dwarf2/dw2-empty-inline-ranges.exp.  After investigation, we
found that the conditions for the test to fail are:

 - running in an environment where GDB can't disable address space
   randomization (such as in a container where that capability is
   removed)

 - a toolchain generating position-independent executables

The test does a first run to grab the addresses of a few labels defined
in the source file.  It then crafts the DWARF using these addresses.
And then it does a second run for the actual test stuff.

When the executable is PIE and ASLR is active, then the addresses in
both runs don't agree, which the test doesn't expect.

It is possible to emulate the failure by inserting some:

    gdb_test_no_output "set disable-randomization off"

after both "prepare_for_testing" calls.  The (first) failure then
manifests as:

    FAIL: gdb.dwarf2/dw2-empty-inline-ranges.exp: dwarf_version=4: empty_loc=start: entry_pc_type=empty: stopped at entry-pc

This test compares the expected stop PC "entry_pc" with the actual stop
PC "pc".  In my example run, they were indeed different:

    pc       = 0x5603ec67a159
    entry_pc = 0x55baba6a9159

The simplest way to fix this, which this patch implements, is to use
"nopie" when building the binaries.  I don't think this affects the
effectiveness of the test.

Also, in the first run, it is longer necessary to run the inferior
before grabbing the addresses, they are going to be the same with a
non-PIE executable.  So remove that.

Change-Id: I3e9b1c056c30a49e01e1a1d3bf28f7e0e409f3c9
Approved-By: Andrew Burgess <aburgess@redhat.com>