Re: [PATCH 14/13] Move errno.h to common-defs.h

Pedro Alves
2014-07-31T09:57:43Z

On 07/31/2014 02:46 AM, Tom Tromey wrote:
>>>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
>
> Gary> This commit moves the inclusion of errno.h to common-defs.h and
> Gary> removes all other inclusions. Note that prior to this commit errno.h
> Gary> was included unconditionally in defs.h, whereas in common-defs.h it is
> Gary> protected by "#ifdef HAVE_ERRNO_H". This does not change the status
> Gary> quo, since presumably every platform on which GDB builds has errno.h.
>
> Gary> Is this ok to commit?
>
> Gary> * configure.ac (AC_CHECK_HEADERS): Add errno.h.
>
> If a header in common/, nat/, or target/ requires an autoconf define,
> then the check should be added to common/common.m4 and then the various
> configure scripts rebuilt.
>
> This way we ensure that gdb and gdbserver keep in sync. There were
> problems with this in the past.
>
> I think it's fine to unconditionally include errno.h. For one thing
> some files in gdb did this.

That's actually not a good justification. We should always check the
history of why the check is on the gdb or gdbserver side. That's
because the set of hosts/ports supported by either side is not a strict
superset of the other side.

The checks for HAVE_ERRNO_H on the gdbserver side were added for the
Windows CE port (as git blame/log will show -- 68070c10). There's no native
gdb Windows CE, so it didn't need that. That said, the CE port is broken
for other (similar) reasons. E.g., the CE port predated use of both libiberty
and gnulib in gdbserver, and libiberty unconditionally includes errno.h as
well, for example. I don't think we should completely nuke the port because
most of the arch abstractions in the Windows target side are needed for
Windows (NT) on ARM anyway, but it's super fine with me to not have it prevent
modernization of the core code base. (If someone were to fix the port, she
just somehow come up with an errno.h replacement and make it available to
all of the build, including libiberty, which doesn't use gnulib.)

> Also I believe it is pulled into gnulib as
> a dependency of some other module; though you'd probably want to check
> this.

Yeah, I think so.

>
> If you go this route then I guess it would be nice to remove errno.h
> checks instead.

Let's do that.

--
Thanks,
Pedro Alves