Re: [PATCH] Move gdbserver to top level

Tom Tromey
2020-01-27T21:28:25Z

>>>>> "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.

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.

Pedro> So I'm thinking that it might be better to document "make
Pedro> all-gdbserver" instead of the --disable approach. Or at least,
Pedro> mention it as alternative. WDYT?

Makes sense, though I may take a stab at fixing the top-level instead.

Pedro> However, looking at how libatomic, liboffloadmic, etc.
Pedro> handle this at the top level, I see that the top level
Pedro> sources a file that is also sourced by their respective
Pedro> configures. I.e., the file sourced served a dual purpose.
Pedro> From the top level, the file is sourced in subshell, which
Pedro> avoids variable polluting the top level. This has the advantage
Pedro> that you only have to write support for a port once in one file,
Pedro> instead of in two places.

Pedro> The equivalent for gdbserver would be the patch below,
Pedro> which seems to work well. Was there a reason you didn't follow
Pedro> libatomic's (etc.) model?

I just didn't think of it. I like your idea better, though, because it
means not duplicating information.

Tom