[RFC/PATCH] Testsuite: set sysroot when using gdbserver

  > On 28 Mar 2019, at 11:32, Pedro Alves <palves@redhat.com> wrote:
> 
> On 03/28/2019 11:02 AM, Alan Hayward wrote:
>> 
>> 
>>> On 28 Mar 2019, at 05:14, Kevin Buettner <kevinb@redhat.com> wrote:
>>> 
>>> Hi Alan,
>>> 
>>> I want to apologize in case my latter comment came across as harsh.  I
>>> think I could have phrased it more diplomatically.
>> 
>> Oh, no, that’s fine :)
>> 
>>> 
>>> I'll note that I also have an interest in setting up sysroot for the
>>> OpenMP tests that I've been working on.  So I am genuinely interested
>>> in whether or how sysroot can be set from a board file.
>>> 
>>> Also, making the tests run faster is definitely a good thing, so
>>> thanks for looking into this.
>> 
> 
> IMO we could also look at this from the perspective that the slowness is
> something that we should tackle, improve in gdb somehow.  For example, we
> could improve caching a lot.  We have a readahead cache for vFile:pread, but
> we could also have a persistent cache layer, so that we wouldn't be
> downloading the same shared library files over and over again.

Will caching only effect extended gdbserver (which AIUI, gdbserver stays alive
between tests)? It’s not an area I’ve (yet) looked at.

> 
>> 
>> I don’t know much about how the board files work, but, looks like I can
>> just add a flag via “set_board_info” in the relevant board files.
>> 
>> I can then check for it at the end of gdbserver_start. Or instead check
>> at the same place “target remote” is run (although I couldn’t find where
>> that was yesterday!).
> 
> Probably just adding
> 
> set GDBFLAGS "${GDBFLAGS} -ex \"set sysroot /\""
> 
> to testsuite/boards/local-board.exp is all you'd need.


That fixes it! And logically makes sense too.
Works fine on the buildbot slave.

> 
> I think it'd be good to have a testcase in gdb.server/ that explicitly
> tests debugging a bit with "set sysroot target:" enabled, so that we
> don't lose coverage of that.

Agreed. Happy to raise that as a new patch next week - trying to avoid
writing anything new as I’m not really here today.

Is the following patch ok for pushing?

Given you told me the line to add, I wasn’t sure if I should be adding you
to the changelog line too :)



    Testsuite: set sysroot when using gdbserver

    When testing using native-gdbserver and native-extended-gdbserver, the sysroot
    is not set.  This results in a warning from GDB and files are sent via the
    remote protocol, which can be slow.

    On Ubuntu 18.04 (unlike most distros) the debug versions of the standard
    libraries are included by default in /usr/lib/debug/.

    These file reads are causing a complete native-gdbserver run on the AArch64
    buildbot slave to timeout after 2.5 hours.  This is also causing the builds
    to back up on the slave.

    The solution is to ensure the sysroot is set to / for all local boards.

    This drastically reduces the time of a test. For example, gdb.base/sigall.exp
    drops from 23 seconds to 4 seconds.
    A full native-gdbserver run on the AArch64 slave now takes 8 minutes.

    gdb/testsuite/ChangeLog:

    2019-03-28  Alan Hayward  <alan.hayward@arm.com>
                Pedro Alves  <palves@redhat.com>

            * boards/local-board.exp: set sysroot to /.
  

On 03/28/2019 12:50 PM, Alan Hayward wrote:
> 

>>
>> IMO we could also look at this from the perspective that the slowness is
>> something that we should tackle, improve in gdb somehow.  For example, we
>> could improve caching a lot.  We have a readahead cache for vFile:pread, but
>> we could also have a persistent cache layer, so that we wouldn't be
>> downloading the same shared library files over and over again.
> 
> Will caching only effect extended gdbserver (which AIUI, gdbserver stays alive
> between tests)? It’s not an area I’ve (yet) looked at.

It'd work for plain target remote too.  What I meant by persistent is that it
would persist across gdb invocations, saved in a cache directory, similarly
to where we put the new index cache.  We could e.g., key that on build id.

> 
>>
>>>
>>> I don’t know much about how the board files work, but, looks like I can
>>> just add a flag via “set_board_info” in the relevant board files.
>>>
>>> I can then check for it at the end of gdbserver_start. Or instead check
>>> at the same place “target remote” is run (although I couldn’t find where
>>> that was yesterday!).
>>
>> Probably just adding
>>
>> set GDBFLAGS "${GDBFLAGS} -ex \"set sysroot /\""
>>
>> to testsuite/boards/local-board.exp is all you'd need.
> 
> 
> That fixes it! And logically makes sense too.
> Works fine on the buildbot slave.
> 
>>
>> I think it'd be good to have a testcase in gdb.server/ that explicitly
>> tests debugging a bit with "set sysroot target:" enabled, so that we
>> don't lose coverage of that.
> 
> Agreed. Happy to raise that as a new patch next week - trying to avoid
> writing anything new as I’m not really here today.

That'd be great, thanks.

> 
> Is the following patch ok for pushing?
> 
> Given you told me the line to add, I wasn’t sure if I should be adding you
> to the changelog line too :)
> 

Fine with me either way.

Patch is OK.

Thanks,
Pedro Alves