[PATCH 5/5] gdb: native target invalid architecture detection

[Pedro Alves]

On 2022-06-08 08:54, Luis Machado wrote:
> On 6/7/22 19:42, Pedro Alves wrote:
>> On 2022-06-07 12:03, Luis Machado via Gdb-patches wrote:
>>
>>> Yeah, sorry for the poor experience. I can confirm your procedure is
>>> correct, and that you built GDB correctly. Unfortunately this part of
>>> the AArch64 port seems to have rotted away given it is a less common
>>> execution scenario.
>>
>> This is actually covered by the testsuite, since:
>>
>> ~~~~~
>> commit 71be1fdc3655a170f4b14d795e5c9e81fcea06ef
>> Author:     Yao Qi <yao.qi@linaro.org>
>> AuthorDate: Tue Jul 7 16:58:19 2015 +0100
>> Commit:     Yao Qi <yao.qi@linaro.org>
>> CommitDate: Tue Jul 7 16:58:19 2015 +0100
>>
>>      Adjust gdb.multi tests for aarch64
>>           Multi-arch related tests under gdb.multi are to compile programs with
>>      the same compiler but different compiler options (-m64 vs -m32).  However,
>>      different compilers are needed to compile both aarch64 program and
>>      arm (aarch32) program.  This patch is to adjust these test cases to
>>      compile programs in different modes with different compiler.
>>           When we use gcc for arm-linux target, its file name can be different,
>>      arm-linux-gnueabihf-gcc, arm-linux-gnueabi-gcc, or arm-none-linux-gnueabi-gcc,
>>      so I add a variable ARM_CC_FOR_TARGET, so that user can set the name
>>      of gcc for arm-linux target on aarch64, like:
>>            $ make check RUNTESTFLAGS='ARM_CC_FOR_TARGET=arm-linux-gnueabihf-gcc multi-arch.exp'
>>           gdb/testsuite:
>>           2015-07-07  Yao Qi  <yao.qi@linaro.org>
>>                   * gdb.multi/multi-arch-exec.exp: Set march1 and march2 to "" if target
>>              is aarch64.  If target is aarch64, set compiler=${ARM_CC_FOR_TARGET}
>>              if it exists.
>>              * gdb.multi/multi-arch.exp: Likewise.
>>
>> ~~~~~
>>
>> I guess the issue is that nobody ever remembers to set ARM_CC_FOR_TARGET, or even
>> knows about it.
> 
> Yeah. As a general comment, I always have to stop and think about the list of things that need
> to be installed in order for GDB's testsuite to run all/most of the tests.

Yes.  I think a nice solution for that would be to have a script under gdb/contrib/ that installs
all the build & test dependencies on per distro basis.  We have some of that in the old buildbot
wiki:

  https://sourceware.org/gdb/wiki/BuildBot#Buildslave_configuration

and also mjw's new buildbot infrastructure also is gaining some docker scripts that know the same.
But I think putting it in gdb/contrib/ would be better so that everyone has easy access to it.

> 
> If you're missing something, most of the time things show up as UNTESTED/UNSUPPORTED. It
> would be nice to have a stable list of things we need to have complete (as much as possible)
> testsuite coverage.
> 
> Having to set these options by hand is quite obscure as well.

Yes, hence my proposed patch in the follow up email.  I think that we should strive to make
just "make check" (with no options) Just Work.

> 
>>
>> IWBN if the aarch64 bots people have access to tested with ARM_CC_FOR_TARGET, if they
>> aren't already.
> 
> I think it is a less common scenario. Yes, this is supported, but my feeling is that people
> seldom use this. Which explains why nobody complained, and some are surprised this even works.
> 

A 64-bit program can always exec a 32-bit program.  Likewise the other way around.  That should be
debuggable with a single gdb.

As you say, it's supported.  So, better test it routinely.  Not testing it doesn't gain us anything,
other than leading to bitrot, as has happened.

>>
>> Maybe it would be possible to come up with a way to default ARM_CC_FOR_TARGET to
>> something that works for most people when testing aarch64, somehow.
> The problem is that a compiler is not enough to make things run fine. If you have an aarch64
> Ubuntu, for example, you'd need to add armhf as an architecture option and install both the
> compiler and the libraries (libc6:armhf mostly).

That is not an issue specific to aarch64.  On x86-64, you need to install extra runtime
packages to test -m32 too, just the compiler isn't enough, and those packages aren't installed
by default.

> 
> Another problem is that not every processor/kernel supports running a 32-bit process in a
> 64-bit environment. This makes things more complicated.
> 

Why "more complicated"?  If you're worried about FAILs in the testsuite, then we can e.g. make it run
the 32-bit program once outside gdb to check that running 32-bits works.  If that fails, then
we don't run the test.  Seems simple, not complicated.