Simplify the IPA parts of the gdbserver Makefile

  Instead of adding the Gnulib CFLAGS and partially undoing them, just
don't add them.

Requires a minor change to common-defs.h, and depends on
https://sourceware.org/ml/gdb-patches/2019-11/msg00908.html

gdb/ChangeLog:

2019-11-26  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/common-defs.h: Don't use Gnulib when building IPA.

gdb/gdbserver/ChangeLog:

2019-11-26  Christian Biesinger  <cbiesinger@google.com>

	* Makefile.in: Don't use Gnulib headers when building IPA.

Change-Id: I93266a721def7e5cd40b5a2f2ed959c70446a2d8
---
 gdb/gdbserver/Makefile.in    | 16 +++++-----------
 gdb/gdbsupport/common-defs.h |  5 ++++-
 2 files changed, 9 insertions(+), 12 deletions(-)
  

On 11/26/19 7:10 PM, Christian Biesinger via gdb-patches wrote:
> Instead of adding the Gnulib CFLAGS and partially undoing them, just
> don't add them.
> 

Currently the IPA uses gnulib headers, but not the function
replacements.  What's the end goal you're after?  Why is this
an improvement?

Thanks,
Pedro Alves
  

On Tue, Nov 26, 2019 at 2:29 PM Pedro Alves <palves@redhat.com> wrote:
>
> On 11/26/19 7:10 PM, Christian Biesinger via gdb-patches wrote:
> > Instead of adding the Gnulib CFLAGS and partially undoing them, just
> > don't add them.
> >
>
> Currently the IPA uses gnulib headers, but not the function
> replacements.  What's the end goal you're after?  Why is this
> an improvement?

Right. The end goal is
https://sourceware.org/ml/gdb-patches/2019-11/msg00922.html -- I want
to be able to call safe_strerror from more places, which means the
implementation of safe_strerror needs to be able to call glibc's
strerror_r. I suppose I could try adding it to UNDO_GNULIB_CFLAGS,
maybe, but it seemed less confusing to change it like this.

Christian
  

On 11/26/19 8:32 PM, Christian Biesinger wrote:
>> Currently the IPA uses gnulib headers, but not the function
>> replacements.  What's the end goal you're after?  Why is this
>> an improvement?
> 
> Right. The end goal is
> https://sourceware.org/ml/gdb-patches/2019-11/msg00922.html -- I want
> to be able to call safe_strerror from more places, which means the
> implementation of safe_strerror needs to be able to call glibc's
> strerror_r. I suppose I could try adding it to UNDO_GNULIB_CFLAGS,
> maybe, but it seemed less confusing to change it like this.
So currently strerror_r is replaced by gnulib and you get a link
error?

What bothers me is that this moves in the direction of having to
handle portability ourselves, effectively undoing the benefits
of gnulib.  It seems to me to walk in the opposite direction of
the ideal, which would be for the IPA to also use gnulib.
It doesn't use gnulib today, because the IPA is a shared library,
so we'd need to link with a build of gnulib built with -fPIC.

The UNDO_GNULIB_CFLAGS stuff at least gives us normalized headers
between gdb / gdbserver / IPA, which for simple header portability
fixes and defines seems good enough, though not ideal, of course.

Thanks,
Pedro Alves
  

On Tue, Nov 26, 2019 at 2:56 PM Pedro Alves <palves@redhat.com> wrote:
>
> On 11/26/19 8:32 PM, Christian Biesinger wrote:
> >> Currently the IPA uses gnulib headers, but not the function
> >> replacements.  What's the end goal you're after?  Why is this
> >> an improvement?
> >
> > Right. The end goal is
> > https://sourceware.org/ml/gdb-patches/2019-11/msg00922.html -- I want
> > to be able to call safe_strerror from more places, which means the
> > implementation of safe_strerror needs to be able to call glibc's
> > strerror_r. I suppose I could try adding it to UNDO_GNULIB_CFLAGS,
> > maybe, but it seemed less confusing to change it like this.
> So currently strerror_r is replaced by gnulib and you get a link
> error?

Yes, exactly.

> What bothers me is that this moves in the direction of having to
> handle portability ourselves, effectively undoing the benefits
> of gnulib.  It seems to me to walk in the opposite direction of
> the ideal, which would be for the IPA to also use gnulib.
> It doesn't use gnulib today, because the IPA is a shared library,
> so we'd need to link with a build of gnulib built with -fPIC.

Oh, is that the only reason? That seems like it should be fixable
reasonably easily, just build gdbserver's gnulib with -fPIC. And if we
move to a single Gnulib build we can just build all of it with -fPIC,
I would think, not much of a downside. I thought there may be codesize
concerns.

> The UNDO_GNULIB_CFLAGS stuff at least gives us normalized headers
> between gdb / gdbserver / IPA, which for simple header portability
> fixes and defines seems good enough, though not ideal, of course.

OK, I'll update that other patch to use that.

Do you think https://sourceware.org/ml/gdb-patches/2019-11/msg00908.html
is still worth having or should I withdraw that too?

Christian
  

On 11/26/19 9:05 PM, Christian Biesinger wrote:
> On Tue, Nov 26, 2019 at 2:56 PM Pedro Alves <palves@redhat.com> wrote:
>>

>> What bothers me is that this moves in the direction of having to
>> handle portability ourselves, effectively undoing the benefits
>> of gnulib.  It seems to me to walk in the opposite direction of
>> the ideal, which would be for the IPA to also use gnulib.
>> It doesn't use gnulib today, because the IPA is a shared library,
>> so we'd need to link with a build of gnulib built with -fPIC.
> 
> Oh, is that the only reason? That seems like it should be fixable
> reasonably easily, just build gdbserver's gnulib with -fPIC. And if we
> move to a single Gnulib build we can just build all of it with -fPIC,
> I would think, not much of a downside. I thought there may be codesize
> concerns.

Yeah, code size concerns went out the window when the IPA started
using std::vector/std::string along with gdbserver...

> 
>> The UNDO_GNULIB_CFLAGS stuff at least gives us normalized headers
>> between gdb / gdbserver / IPA, which for simple header portability
>> fixes and defines seems good enough, though not ideal, of course.
> 
> OK, I'll update that other patch to use that.
> 
> Do you think https://sourceware.org/ml/gdb-patches/2019-11/msg00908.html
> is still worth having or should I withdraw that too?
That seems still worth it for being more direct to the point / precise.

Thanks,
Pedro Alves