gnulib's errno module was imported

gnulib's errno module was imported

[Yao Qi]

Hi,
When I audit gnulib modules imported to gdb, I find that errno is in,
which was imported as the dependency of "dirfd" module in commit
18848e288ca9d1ca242cce667419bbb6728442fc  The motivation of importing
"dirfd" module is to make gdb compatible with LSB 3.0 (see
https://sourceware.org/ml/gdb/2014-02/msg00034.html).

However, we've already had a conclusion that we don't import gnulib's
errno module because it has some compatibility issues with libiconv
(discussed in https://sourceware.org/ml/gdb-patches/2012-12/msg00554.html).
AFAICS, the argument that not having errno module at that moment is
still valid today.

I am inclined to back "dirfd" (and "errno") module out.  As a result,
gdb will not be compatible with LSB 3.0, but it is just a minor issue to
me.  What do you think?

-- 
Yao (齐尧)

Re: gnulib's errno module was imported

[Eli Zaretskii]

> From: Yao Qi <yao@codesourcery.com>
> CC: <gregory.0xf0@gmail.com>
> Date: Fri, 14 Nov 2014 13:44:49 +0800
> 
> I am inclined to back "dirfd" (and "errno") module out.  As a result,
> gdb will not be compatible with LSB 3.0, but it is just a minor issue to
> me.  What do you think?

Is it possible to back out dirfd, and then add to GDB whatever glue
(borrowed from gnulib) that's needed to support LSB 3.0?  IOW, can we
support LSB 3.0 in our own code, either inspired or stolen from
gnulib?

IME, gnulib many times includes a lot of overhead in its solutions for
problems, while the minimal change to fix the specific problem can be
much more lightweight and simple.  the question is can we go this way
in this case?

Thanks.

Re: gnulib's errno module was imported

[Yao Qi]

Eli Zaretskii <eliz@gnu.org> writes:

> Is it possible to back out dirfd, and then add to GDB whatever glue
> (borrowed from gnulib) that's needed to support LSB 3.0?  IOW, can we
> support LSB 3.0 in our own code, either inspired or stolen from
> gnulib?

We can do that but I suspect the value of doing that.  How important is
it to keep GDB head compatible with LSB 3.0 which was released on 2005?
Maybe distro people are aware of this, but I don't know.

-- 
Yao (齐尧)

Re: gnulib's errno module was imported

[Gregory Fong]

On Fri, Nov 14, 2014 at 12:30 AM, Yao Qi <yao@codesourcery.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Is it possible to back out dirfd, and then add to GDB whatever glue
>> (borrowed from gnulib) that's needed to support LSB 3.0?  IOW, can we
>> support LSB 3.0 in our own code, either inspired or stolen from
>> gnulib?
>
> We can do that but I suspect the value of doing that.  How important is
> it to keep GDB head compatible with LSB 3.0 which was released on 2005?
> Maybe distro people are aware of this, but I don't know.

I'm not opposed to something more lightweight than importing gnulib's
dirfd, but RHEL 4 (LSB 3.0) is in extended support through 2017, so I
think there's still value in LSB 3.0 compatibility.

Cheers,
Gregory

Re: gnulib's errno module was imported

[Eli Zaretskii]

> From: Yao Qi <yao@codesourcery.com>
> CC: <gdb-patches@sourceware.org>, <gregory.0xf0@gmail.com>
> Date: Fri, 14 Nov 2014 16:30:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is it possible to back out dirfd, and then add to GDB whatever glue
> > (borrowed from gnulib) that's needed to support LSB 3.0?  IOW, can we
> > support LSB 3.0 in our own code, either inspired or stolen from
> > gnulib?
> 
> We can do that but I suspect the value of doing that.  How important is
> it to keep GDB head compatible with LSB 3.0 which was released on 2005?

I don't know.  I assumed that supporting LSB 3.0 was important; if
not, then just backing out dirfd, as you suggested, is TRT.

Re: gnulib's errno module was imported

[Joel Brobecker]

> I am inclined to back "dirfd" (and "errno") module out.  As a result,
> gdb will not be compatible with LSB 3.0, but it is just a minor issue to
> me.  What do you think?

I don't have any strong feeling, but I am wondering, now that
errno snuck in, whether we might just wait and see if it actually
really causes problems in practice? I have a feeling that the errno
module will keep wanting to get in, so this is perhaps our chance
to try to work this one out.

-- 
Joel

Re: gnulib's errno module was imported

[Pedro Alves]

On 11/14/2014 05:44 AM, Yao Qi wrote:

> However, we've already had a conclusion that we don't import gnulib's
> errno module because it has some compatibility issues with libiconv
> (discussed in https://sourceware.org/ml/gdb-patches/2012-12/msg00554.html).
> AFAICS, the argument that not having errno module at that moment is
> still valid today.

I think this will keep haunting and blocking us until we fix it.

Can we reevaluate this?

To recap, the issue is that GNU iconv does this:

/* Get errno declaration and values. */
#include <errno.h>
/* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
   have EILSEQ in a different header.  On these systems, define EILSEQ
   ourselves. */
#ifndef EILSEQ
#define EILSEQ @EILSEQ@
#endif

That's in:

 http://git.savannah.gnu.org/cgit/libiconv.git/tree/include/iconv.h.in

The "different header" mentioned is wchar.h.  This is handled in:

  http://git.savannah.gnu.org/cgit/libiconv.git/tree/m4/eilseq.m4

which defines @EILSEQ@ to EINVAL if EILSEQ isn't found in
either errno.h or wchar.h.

As we dropped support for both SunOS 4 or old BSD/OS, maybe we
don't need to care about the wchar.h issue anymore.
Still, AFAICS, gnulib's m4/errno_h.m4 doesn't know that EILSEQ may be
defined in wchar.h, and so on such systems, ISTM gnulib ends up defining
an incompatible EILSEQ itself, but I think that should be fixed on
the gnulib side, by making it extract the EILSEQ value out of the
system's wchar.h, like GNU iconv does.

So that leaves handling the case of gnulib making up a EILSEQ value,
which we take as meaning the system really doesn't really define it,
which will be the systems GNU iconv returns ENOENT instead.

With that rationale, how about we try something like this?

The current EILSEQ definition under PHONY_ICONV is obviously stale
as gnulib garantees there's always a EILSEQ defined.

From ccf843befc9750bb0b8fb18296c1352b9ddef855 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 14 Nov 2014 10:29:03 +0000
Subject: [PATCH] handle iconv defining EILSEQ to ENOENT

---
 gdb/charset.c | 35 +++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/gdb/charset.c b/gdb/charset.c
index 94ad020..d71321e 100644
--- a/gdb/charset.c
+++ b/gdb/charset.c
@@ -95,15 +95,6 @@
 #undef ICONV_CONST
 #define ICONV_CONST const
 
-/* Some systems don't have EILSEQ, so we define it here, but not as
-   EINVAL, because callers of `iconv' want to distinguish EINVAL and
-   EILSEQ.  This is what iconv.h from libiconv does as well.  Note
-   that wchar.h may also define EILSEQ, so this needs to be after we
-   include wchar.h, which happens in defs.h through gdb_wchar.h.  */
-#ifndef EILSEQ
-#define EILSEQ ENOENT
-#endif
-
 static iconv_t
 phony_iconv_open (const char *to, const char *from)
 {
@@ -187,8 +178,32 @@ phony_iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft,
   return 0;
 }
 
-#endif
+#else /* PHONY_ICONV */
+
+/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
+   to ENOENT.  gnulib instead defines it to a different value.  On
+   such systems, map ENOENT to gnulib's EILSEQ, leaving callers
+   agnostic.  */
+#ifdef GNULIB_defined_EILSEQ
+
+static size_t
+gdb_iconv (iconv_t utf_flag, ICONV_CONST char **inbuf, size_t *inbytesleft,
+	   char **outbuf, size_t *outbytesleft)
+{
+  size_t ret;
+
+  ret = iconv (utf_flag, inbuf, inbytesleft, outbuf, outbytesleft);
+  if (errno == ENOENT)
+    errno = EILSEQ;
+  return ret;
+}
 
+#undef iconv
+#define iconv gdb_iconv
+
+#endif /* GNULIB_defined_EILSEQ */
+
+#endif /* PHONY_ICONV */
 
 \f
 /* The global lists of character sets and translations.  */
-- 
1.9.3

Re: gnulib's errno module was imported

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> I think this will keep haunting and blocking us until we fix it.
>

Let us try again to fix it.

> Can we reevaluate this?

Sure.

> So that leaves handling the case of gnulib making up a EILSEQ value,
> which we take as meaning the system really doesn't really define it,
> which will be the systems GNU iconv returns ENOENT instead.
>
> With that rationale, how about we try something like this?

I am fine with your approach, but I am wondering why don't we simply
check ENOENT in the places where we check EILSEQ?

@@ -513,6 +513,7 @@ convert_between_encodings (const char *from, const char *to,
 	  switch (errno)
 	    {
 	    case EILSEQ:
+	    case ENOENT:
 	      {
 		int i;
 
@@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter,
 	  switch (errno)
 	    {
 	    case EILSEQ:
+	    case ENOENT:
 	      /* Invalid input sequence.  We still might have
 		 converted a character; if so, return it.  */
 	      if (out_avail < out_request * sizeof (gdb_wchar_t))

This looks cleaner to me (some comments should be added, of course).

-- 
Yao (齐尧)

Re: gnulib's errno module was imported

[Pedro Alves]

On 11/14/2014 01:01 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> I think this will keep haunting and blocking us until we fix it.
>>
> 
> Let us try again to fix it.
> 
>> Can we reevaluate this?
> 
> Sure.
> 
>> So that leaves handling the case of gnulib making up a EILSEQ value,
>> which we take as meaning the system really doesn't really define it,
>> which will be the systems GNU iconv returns ENOENT instead.
>>
>> With that rationale, how about we try something like this?
> 
> I am fine with your approach, but I am wondering why don't we simply
> check ENOENT in the places where we check EILSEQ?
> 
> @@ -513,6 +513,7 @@ convert_between_encodings (const char *from, const char *to,
>  	  switch (errno)
>  	    {
>  	    case EILSEQ:
> +	    case ENOENT:
>  	      {
>  		int i;
>  
> @@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter,
>  	  switch (errno)
>  	    {
>  	    case EILSEQ:
> +	    case ENOENT:
>  	      /* Invalid input sequence.  We still might have
>  		 converted a character; if so, return it.  */
>  	      if (out_avail < out_request * sizeof (gdb_wchar_t))
> 
> This looks cleaner to me (some comments should be added, of course).

That was actually my first approach, but then:

 - I thought that having a central place to handle this
   and to put the comment was cleaner than repeating the fix
   in multiple places.
 - That won't build on systems that EILSEQ and ENOENT are
   defined to the same value (two switch cases with the same value).
   Not sure there are any such systems, but given iconv.h's practice...

I guess I could also simplify and remove the GNULIB_defined_EILSEQ
guard, mapping ENOENT to EILSEQ everywhere ?

+/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
+   to ENOENT.  gnulib instead defines it to a different value.  On
+   such systems, map ENOENT to gnulib's EILSEQ, leaving callers
+   agnostic.  */
+#ifdef GNULIB_defined_EILSEQ

I looked at glibc's iconv and it seems that ENOENT is never used
there, so should be safe.

Thanks,
Pedro Alves

Re: gnulib's errno module was imported

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> That was actually my first approach, but then:
>
>  - I thought that having a central place to handle this
>    and to put the comment was cleaner than repeating the fix
>    in multiple places.
>  - That won't build on systems that EILSEQ and ENOENT are
>    defined to the same value (two switch cases with the same value).
>    Not sure there are any such systems, but given iconv.h's practice...
>
> I guess I could also simplify and remove the GNULIB_defined_EILSEQ
> guard, mapping ENOENT to EILSEQ everywhere ?

I don't have a strong feeling on this, so either is OK to me.

>
> +/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
> +   to ENOENT.  gnulib instead defines it to a different value.  On
> +   such systems, map ENOENT to gnulib's EILSEQ, leaving callers
> +   agnostic.  */
> +#ifdef GNULIB_defined_EILSEQ
>
> I looked at glibc's iconv and it seems that ENOENT is never used
> there, so should be safe.

Good, could you please commit your patch?

-- 
Yao (齐尧)

Re: gnulib's errno module was imported

[Pedro Alves]

On 11/14/2014 01:53 PM, Yao Qi wrote:

>> +/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
>> +   to ENOENT.  gnulib instead defines it to a different value.  On
>> +   such systems, map ENOENT to gnulib's EILSEQ, leaving callers
>> +   agnostic.  */
>> +#ifdef GNULIB_defined_EILSEQ
>>
>> I looked at glibc's iconv and it seems that ENOENT is never used
>> there, so should be safe.
> 
> Good, could you please commit your patch?

Here's the updated patch.  I've now regtested it.

Joel, WDYT?

From 42d3b511ccd72ee267f387c0f03ac2b6fe553125 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 14 Nov 2014 10:29:03 +0000
Subject: [PATCH] handle 'iconv's that define EILSEQ to ENOENT

We're currently pulling gnulib's errno module as a dependency of some
other module.  That provides an errno.h that defines EILSEQ to a
distinct value if the system's errno.h doesn't define it already.

However, GNU iconv does this:

 /* Get errno declaration and values. */
 #include <errno.h>
 /* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
    have EILSEQ in a different header.  On these systems, define EILSEQ
    ourselves. */
 #ifndef EILSEQ
 #define EILSEQ @EILSEQ@
 #endif

That's in:

 http://git.savannah.gnu.org/cgit/libiconv.git/tree/include/iconv.h.in

The "different header" mentioned is wchar.h.  This is handled in:

 http://git.savannah.gnu.org/cgit/libiconv.git/tree/m4/eilseq.m4

which defines @EILSEQ@ to ENOENT if EILSEQ isn't found in either
errno.h or wchar.h.

So if iconv sets errno to EILSEQ on such system's, it's really setting
it to ENOENT.  And when we check for EILSEQ, we're checking for
gnulib's value.  The result is we won't detect the error correctly.

As we dropped support for both SunOS 4 or old BSD/OS, maybe we don't
need to care about the wchar.h issue anymore.  Still, AFAICS, gnulib's
m4/errno_h.m4 doesn't know that EILSEQ may be defined in wchar.h, and
so on such systems, ISTM gnulib ends up defining an incompatible
EILSEQ itself, but I think that should be fixed on the gnulib side, by
making it extract the EILSEQ value out of the system's wchar.h, like
GNU iconv does.

So that leaves handling the case of gnulib making up a EILSEQ value,
which we take as meaning the system really doesn't really define it,
which will be the same systems GNU iconv sets errno to ENOENT instead
of EILSEQ.

Looking at glibc's iconv it seems that ENOENT is never used there.
It seems it's safe to always treat ENOENT the same as EILSEQ.

The current EILSEQ definition under PHONY_ICONV is obviously stale as
gnulib garantees there's always a EILSEQ defined.

Tested on x86_64 Fedora 20.

gdb/
2014-11-14  Pedro Alves  <palves@redhat.com>

	* charset.c [PHONY_ICONV && !EILSEQ] (EILSEQ): Don't define.
	[!PHONY_ICONV] (gdb_iconv): New function.
	[!PHONY_ICONV] (iconv): Redefine to gdb_iconv.
---
 gdb/charset.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/gdb/charset.c b/gdb/charset.c
index 94ad020..2712939 100644
--- a/gdb/charset.c
+++ b/gdb/charset.c
@@ -95,15 +95,6 @@
 #undef ICONV_CONST
 #define ICONV_CONST const
 
-/* Some systems don't have EILSEQ, so we define it here, but not as
-   EINVAL, because callers of `iconv' want to distinguish EINVAL and
-   EILSEQ.  This is what iconv.h from libiconv does as well.  Note
-   that wchar.h may also define EILSEQ, so this needs to be after we
-   include wchar.h, which happens in defs.h through gdb_wchar.h.  */
-#ifndef EILSEQ
-#define EILSEQ ENOENT
-#endif
-
 static iconv_t
 phony_iconv_open (const char *to, const char *from)
 {
@@ -187,8 +178,28 @@ phony_iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft,
   return 0;
 }
 
-#endif
+#else /* PHONY_ICONV */
 
+/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
+   to ENOENT, while gnulib defines it to a different value.  Always
+   map ENOENT to gnulib's EILSEQ, leaving callers agnostic.  */
+
+static size_t
+gdb_iconv (iconv_t utf_flag, ICONV_CONST char **inbuf, size_t *inbytesleft,
+	   char **outbuf, size_t *outbytesleft)
+{
+  size_t ret;
+
+  ret = iconv (utf_flag, inbuf, inbytesleft, outbuf, outbytesleft);
+  if (errno == ENOENT)
+    errno = EILSEQ;
+  return ret;
+}
+
+#undef iconv
+#define iconv gdb_iconv
+
+#endif /* PHONY_ICONV */
 
 \f
 /* The global lists of character sets and translations.  */
-- 
1.9.3

Re: gnulib's errno module was imported

[Joel Brobecker]

> Here's the updated patch.  I've now regtested it.
>
> Joel, WDYT?

Thanks, Pedro. That looks pretty good to me!

> gdb/
> 2014-11-14  Pedro Alves  <palves@redhat.com>
> 
> 	* charset.c [PHONY_ICONV && !EILSEQ] (EILSEQ): Don't define.
> 	[!PHONY_ICONV] (gdb_iconv): New function.
> 	[!PHONY_ICONV] (iconv): Redefine to gdb_iconv.

-- 
Joel

Re: gnulib's errno module was imported

[Pedro Alves]

On 11/14/2014 03:18 PM, Joel Brobecker wrote:
>> Here's the updated patch.  I've now regtested it.
>>
>> Joel, WDYT?
> 
> Thanks, Pedro. That looks pretty good to me!

Alright, now pushed.

Thanks,
Pedro Alves

Re: gnulib's errno module was imported

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> Alright, now pushed.

Thanks, Pedro.

-- 
Yao (齐尧)

Re: gnulib's errno module was imported

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 13:21:01 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org, gregory.0xf0@gmail.com,        Joel Brobecker <brobecker@adacore.com>
> 
> > @@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter,
> >  	  switch (errno)
> >  	    {
> >  	    case EILSEQ:
> > +	    case ENOENT:
> >  	      /* Invalid input sequence.  We still might have
> >  		 converted a character; if so, return it.  */
> >  	      if (out_avail < out_request * sizeof (gdb_wchar_t))
> > 
> > This looks cleaner to me (some comments should be added, of course).
> 
> That was actually my first approach, but then:
> 
>  - I thought that having a central place to handle this
>    and to put the comment was cleaner than repeating the fix
>    in multiple places.
>  - That won't build on systems that EILSEQ and ENOENT are
>    defined to the same value (two switch cases with the same value).
>    Not sure there are any such systems, but given iconv.h's practice...

The last one is easy:

  	    case EILSEQ:
 +#if EILSEQ != ENOENT
 +	    case ENOENT:
 +#endif

Re: gnulib's errno module was imported

[Pedro Alves]

On 11/14/2014 02:31 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>

>> That was actually my first approach, but then:
>>
>>  - I thought that having a central place to handle this
>>    and to put the comment was cleaner than repeating the fix
>>    in multiple places.
>>  - That won't build on systems that EILSEQ and ENOENT are
>>    defined to the same value (two switch cases with the same value).
>>    Not sure there are any such systems, but given iconv.h's practice...
> 
> The last one is easy:
> 
>   	    case EILSEQ:
>  +#if EILSEQ != ENOENT
>  +	    case ENOENT:
>  +#endif

Agreed, but then having to do that in multiple places
seems even uglier.  :-)

Thanks,
Pedro Alves