Re: [PATCHv4 00/10] x86/Linux Target Description Changes

[John Baldwin <jhb@FreeBSD.org>]

On 4/5/24 8:33 AM, Andrew Burgess wrote:
> In v4:
> 
>    - I tried merging V3, but it turned out I broke pretty much
>      everything that wasn't x86 based when configured with
>      --enable-targets=all,
> 
>    - The problem was a failure to correctly split the shared code
>      between the gdb/arch/ and gdb/nat/ directories, as a consequence,
>      code which is needed on a non x86 based host to support x86 based
>      targets wasn't available to the compilation, and the build failed,
> 
>    - In V4 I've gone through every patch and resplit the code in a way
>      which I now believe is correct, I've done the following tests:
> 
>      + On a non x86 host I've built GDB to support only the current
>      host as a target, to support all targets, and to support x86-64
>      and i386 linux targets,
> 
>      + On an i386 virtual machine I built GDB only for the host as a
>      target, and for all targets.  I regression tested the all targets
>      build for unix, native-gdbserver, and native-extended-gdbserver,
> 
>      + On an x86-64 machine I've built GDB for only the current host as
>      a target, and for all targets.  I regression tested the all targets
>      build for unix, native-gdbserver, and native-extended-gdbserver.
> 
>    - Only patches 6, 8, and 10 require significant review.  All of the
>      other patches are pretty trivial (though reviews always welcome).
> 
>    - I think there's more improvements that can be made to the x86
>      target description creation/lookup/caching.  This series only
>      changes the Linux lookup, and we still cache i386/amd64/x32
>      separately.
> 
>      In the future I think we can merge all x86 target description
>      caching into a single data structure, this would be for all OS
>      variants and all ABI variants.
> 
>      Though making that "grand unification" will certainly require some
>      of the code in this series to change, I think the bulk of it will
>      remain, and trying to do everything in one series is just going to
>      result in an even larger series.  I'd prefer to get these first
>      patches merged, then come back to build on this work once this is
>      merged and we know there's no problems with it.
> 
> In v3:
> 
>    - Rebased.  Nasty merge conflict with 4bb20a6244b7091 which I think
>      I've resolved, but am unable to test.  Reposting so the author of
>      that other commit can validate.
> 
>    - Initial testing looks good.  Full tests are still running.
> 
> In v2:
> 
>    - Rebase to current upstream/master, no merge conflicts,
> 
>    - Retested.

I re-read this series and it does look ok to me still, but I thought V3 was
ok as well. :-P  Your testing matrix described above for V4 seems reasonable
for catching what you ran into with V3.

Approved-By: John Baldwin <jhb@FreeBSD.org>

-- 
John Baldwin