Re: [PATCH] Move gdbserver to top level

[Pedro Alves <palves at redhat dot com>]

On 1/27/20 9:28 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> I guess it's the intended design for top level to build readline, bfd,
> Pedro> etc.  by default even if no application is being built that depends
> Pedro> on them.  I don't know.
> 
> Me neither, but it seems to me that we could try to change it.  My
> mental model is that there are certain top-level build targets (gdb, or
> binutils) and the rest are just dependencies of those.  So, we could try
> not to build these dependencies unless there's a need.

That was my model as well.  I had never noticed it was different until
now.

> 
> Pedro> People may trip on this if they try to build gdbserver for a port
> Pedro> for which one of those top level dirs doesn't build, like bfd.
> Pedro> powerpc-lynxos is I think one such case, but there are probably
> Pedro> others in the non-glibc space, and also off tree.
> 
> FWIW there is a problem here I haven't solved yet.  Right now, the
> top-level gdbsupport depends on BFD.  This is needed for common-types.h.
> 
> However, this introduces a conflict if we want to share the top-level
> gdbsupport with gdbserver.
> 
> I'm not totally sure what to do here.  Maybe we could replicate the BFD
> type-configury code?  Like, break it out into a new .m4 file for
> sharing.  It's been a while though, so I forget why, but I thought I had
> some reason this wouldn't work.

Yeah.

For ULONGEST/LONGEST, I think we can just assume long long or uint64_t
is available nowadays instead of relying on bfd.  We have been using
long long and uint64_t in common code for quite a while and nobody
has complained.

I think the main thing is CORE_ADDR/bfd_vma.  For that, I'm not sure
either.  Sharing the type-configury with an .m4 should work, I think.

Another option is to use the gdbserver version of the types on gdb as well,
in effect assuming 64-bit CORE_ADDR even on 32-bit hosts.  There may be
some fallout in some code assuming bfd_vma == CORE_ADDR, but probably not
that much.  

I'm not sure whether that would cause a significant performance/memory
degradation on 32-bit hosts for using 64-bit CORE_ADDR, significant enough
to worry about it.  I'm inclined to think that it isn't.  That the main
motivation for the type-configury was that 32-bit compilers in the old days
didn't support 64-bit types.  It's effectively the same as configuring
with --enable-64-bit-bfd.

Thanks,
Pedro Alves