GDB13 fails to build on MacOS using supplied GNU Bison 2.3

GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Torbjorn SVENSSON]

Hello,

I'm trying to build GDB13 for arm-none-eabi on MacOS and have some mixed 
results.
It looks like after b2bc564fe817f857b4915903f16026472acfbdcc got merged, 
the Bison version included in least Mojave, Catalina and Ventura is 
having trouble to generate code that can be compiled.

Snippet of the build error:

       YACC   m2-exp.c
       CXX    m2-exp.o
     In file included from .../gdb/m2-exp.y:42:
     In file included from .../gdb/language.h:26:
     In file included from .../gdb/symtab.h:39:
     .../gdb/split-name.h:34:3: error: expected identifier
       DOT,
       ^
     m2-exp.c:163:13: note: expanded from macro 'DOT'
     #define DOT 302
                 ^
     In file included from .../gdb/m2-exp.y:42:
     In file included from .../gdb/language.h:26:
     .../gdb/symtab.h:307:23: error: expected unqualified-id
             style = split_style::DOT;
                                  ^
     m2-exp.c:163:13: note: expanded from macro 'DOT'
     #define DOT 302
                 ^
     2 errors generated.


All three versions of MacOS includes GNU Bison 2.3 and it appears that 
this issue was fixed in GNU Bison 2.4.

The change between GNU Bison 2.3 and 2.4 for the m2-exp.c file is that 
the include statements are placed before the list of token kinds (define 
statements, including the define for DOT that is used in an enum 
definition in symtab.h).


Looking at the binutils tree, I see that sub-directory gprofng contains 
bison.m4 and a check to confirm that at least version 3.0.4 is available.

I think the bison.m4 file should be moved up one level and used in both 
gprofng and gdb, but I'm unable to re-generate the configure scripts.

Can someone with knowledge of how automake works fix this?

(CC'ing you Tom as you were the one introducing the split-name.h file 
that highlights this flaw.)

Kind regards,
Torbjörn

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom de Vries]

On 8/19/23 20:11, Torbjorn SVENSSON via Gdb wrote:
> Hello,
> 
> I'm trying to build GDB13 for arm-none-eabi on MacOS and have some mixed 
> results.
> It looks like after b2bc564fe817f857b4915903f16026472acfbdcc got merged, 
> the Bison version included in least Mojave, Catalina and Ventura is 
> having trouble to generate code that can be compiled.
> 
> Snippet of the build error:
> 
>        YACC   m2-exp.c
>        CXX    m2-exp.o
>      In file included from .../gdb/m2-exp.y:42:
>      In file included from .../gdb/language.h:26:
>      In file included from .../gdb/symtab.h:39:
>      .../gdb/split-name.h:34:3: error: expected identifier
>        DOT,
>        ^
>      m2-exp.c:163:13: note: expanded from macro 'DOT'
>      #define DOT 302
>                  ^
>      In file included from .../gdb/m2-exp.y:42:
>      In file included from .../gdb/language.h:26:
>      .../gdb/symtab.h:307:23: error: expected unqualified-id
>              style = split_style::DOT;
>                                   ^
>      m2-exp.c:163:13: note: expanded from macro 'DOT'
>      #define DOT 302
>                  ^
>      2 errors generated.
> 
> 

Filed earlier here ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=30286 ).

Thanks,
- Tom

> All three versions of MacOS includes GNU Bison 2.3 and it appears that 
> this issue was fixed in GNU Bison 2.4.
> 
> The change between GNU Bison 2.3 and 2.4 for the m2-exp.c file is that 
> the include statements are placed before the list of token kinds (define 
> statements, including the define for DOT that is used in an enum 
> definition in symtab.h).
> 
> 
> Looking at the binutils tree, I see that sub-directory gprofng contains 
> bison.m4 and a check to confirm that at least version 3.0.4 is available.
> 
> I think the bison.m4 file should be moved up one level and used in both 
> gprofng and gdb, but I'm unable to re-generate the configure scripts.
> 
> Can someone with knowledge of how automake works fix this?
> 
> (CC'ing you Tom as you were the one introducing the split-name.h file 
> that highlights this flaw.)
> 

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom Tromey]

>>>>> "Torbjorn" == Torbjorn SVENSSON via Gdb <gdb@sourceware.org> writes:

Torbjorn> All three versions of MacOS includes GNU Bison 2.3 and it appears that
Torbjorn> this issue was fixed in GNU Bison 2.4.

If the appended works for you (be sure to run some tests), I can check
it in.

Torbjorn> Looking at the binutils tree, I see that sub-directory gprofng
Torbjorn> contains bison.m4 and a check to confirm that at least version 3.0.4
Torbjorn> is available.

Torbjorn> I think the bison.m4 file should be moved up one level and used in
Torbjorn> both gprofng and gdb, but I'm unable to re-generate the configure
Torbjorn> scripts.

I wonder if this would really help you, since presumably it would just
reject your bison?

Another option might be to install bison from brew.  In this case it's
probably fine but eventually we may want to require a newer Bison, and
IMO we can't and shouldn't keep catering to Apple's problem
indefinitely.

Tom

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Torbjorn SVENSSON]

Hello Tom,

On 2023-08-31 15:31, Tom Tromey wrote:
>>>>>> "Torbjorn" == Torbjorn SVENSSON via Gdb <gdb@sourceware.org> writes:
> 
> Torbjorn> All three versions of MacOS includes GNU Bison 2.3 and it appears that
> Torbjorn> this issue was fixed in GNU Bison 2.4.
> 
> If the appended works for you (be sure to run some tests), I can check
> it in.

Not sure what you mean by "appended" here... I see no attachment and my 
mail clarily stated that I could not generate the configure script using 
the autotools.

> Torbjorn> Looking at the binutils tree, I see that sub-directory gprofng
> Torbjorn> contains bison.m4 and a check to confirm that at least version 3.0.4
> Torbjorn> is available.
> 
> Torbjorn> I think the bison.m4 file should be moved up one level and used in
> Torbjorn> both gprofng and gdb, but I'm unable to re-generate the configure
> Torbjorn> scripts.
> 
> I wonder if this would really help you, since presumably it would just
> reject your bison?

Well, what I was thinking was to have something telling the user that 
the sources requires version x.y of bison rather than silently breaking 
during the compile stage with some obscure error message.

> Another option might be to install bison from brew.  In this case it's
> probably fine but eventually we may want to require a newer Bison, and
> IMO we can't and shouldn't keep catering to Apple's problem
> indefinitely.

Yes, this is how I solved it on out system, but it's still not as 
helpful as a configure error would have been to let others know that the 
bison version is too old...

Regards,
Torbjörn

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom Tromey]

Torbjorn> Not sure what you mean by "appended" here... I see no attachment and
Torbjorn> my mail clarily stated that I could not generate the configure script
Torbjorn> using the autotools.

Sorry, forgot to append it.

Tom

diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c
index d6531260c86..58ea541a5c9 100644
--- a/gdb/dwarf2/cooked-index.c
+++ b/gdb/dwarf2/cooked-index.c
@@ -267,7 +267,7 @@ cooked_index_shard::handle_gnat_encoded_entry (cooked_index_entry *entry,
   if (canonical.empty ())
     return {};
   std::vector<gdb::string_view> names = split_name (canonical.c_str (),
-						    split_style::DOT);
+						    split_style::DOT_STYLE);
   gdb::string_view tail = names.back ();
   names.pop_back ();
 
diff --git a/gdb/split-name.h b/gdb/split-name.h
index 47896cc4406..e385ed7dba5 100644
--- a/gdb/split-name.h
+++ b/gdb/split-name.h
@@ -30,8 +30,9 @@ enum class split_style
   NONE,
   /* C++ style, with "::" and template parameter intelligence.  */
   CXX,
-  /* Split at ".".  Used by Ada, Go, D.  */
-  DOT,
+  /* Split at ".".  Used by Ada, Go, D.  This has a name to work
+     around a bug in Bison 2.3, which is used on macOS.  */
+  DOT_STYLE,
   /* Split at "__".  Used by Ada encoded names.  */
   UNDERSCORE,
 };
diff --git a/gdb/symtab.h b/gdb/symtab.h
index ee4729b14cd..ae9816dfc7d 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -305,7 +305,7 @@ class lookup_name_info final
 	break;
       case language_d:
       case language_go:
-	style = split_style::DOT;
+	style = split_style::DOT_STYLE;
 	break;
       }
     return ::split_name (language_lookup_name (lang), style);

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Martin Simmons]

>>>>> On Thu, 31 Aug 2023 12:44:20 -0600, Tom Tromey said:
> 
> Torbjorn> Not sure what you mean by "appended" here... I see no attachment and
> Torbjorn> my mail clarily stated that I could not generate the configure script
> Torbjorn> using the autotools.
> 
> Sorry, forgot to append it.

Also need to patch gdb/split-name.c?

__Martin

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom Tromey]

Martin> Also need to patch gdb/split-name.c?

Really thought I built it but apparently not.  Thanks.

Tom

diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c
index d6531260c86..58ea541a5c9 100644
--- a/gdb/dwarf2/cooked-index.c
+++ b/gdb/dwarf2/cooked-index.c
@@ -267,7 +267,7 @@ cooked_index_shard::handle_gnat_encoded_entry (cooked_index_entry *entry,
   if (canonical.empty ())
     return {};
   std::vector<gdb::string_view> names = split_name (canonical.c_str (),
-						    split_style::DOT);
+						    split_style::DOT_STYLE);
   gdb::string_view tail = names.back ();
   names.pop_back ();
 
diff --git a/gdb/split-name.c b/gdb/split-name.c
index a50a6fa4946..0253b3cf675 100644
--- a/gdb/split-name.c
+++ b/gdb/split-name.c
@@ -58,7 +58,7 @@ split_name (const char *name, split_style style)
 	}
       break;
 
-    case split_style::DOT:
+    case split_style::DOT_STYLE:
       /* D and Go-style names.  */
       for (const char *iter = strchr (name, '.');
 	   iter != nullptr;
diff --git a/gdb/split-name.h b/gdb/split-name.h
index 47896cc4406..7648cf9b900 100644
--- a/gdb/split-name.h
+++ b/gdb/split-name.h
@@ -30,8 +30,9 @@ enum class split_style
   NONE,
   /* C++ style, with "::" and template parameter intelligence.  */
   CXX,
-  /* Split at ".".  Used by Ada, Go, D.  */
-  DOT,
+  /* Split at ".".  Used by Ada, Go, D.  This has a funny name to work
+     around a bug in Bison 2.3, which is used on macOS.  */
+  DOT_STYLE,
   /* Split at "__".  Used by Ada encoded names.  */
   UNDERSCORE,
 };
diff --git a/gdb/symtab.h b/gdb/symtab.h
index ca3b1a4a0b6..8f587807ff9 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -305,7 +305,7 @@ class lookup_name_info final
 	break;
       case language_d:
       case language_go:
-	style = split_style::DOT;
+	style = split_style::DOT_STYLE;
 	break;
       }
     return ::split_name (language_lookup_name (lang), style);

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Torbjorn SVENSSON]

Hi Tom,

Sorry for taking so long to check your patch, but I've been OoO for the 
past 2 weeks.

What type of tests did you have in mind when you, in a previous mail in 
the same thread, wrote:

   If the appended works for you (be sure to run some tests), I can check
   it in.

Is it sufficient with a simple C project and a simple C++ project (my 
example was using std::vector to get some namespace and template 
expansion) built for arm-none-eabi? Those 2 projects appears to work as 
expected anyway.

Kind regards,
Torbjörn



On 2023-09-01 15:02, Tom Tromey wrote:
> Martin> Also need to patch gdb/split-name.c?
> 
> Really thought I built it but apparently not.  Thanks.
> 
> Tom
> 
> diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c
> index d6531260c86..58ea541a5c9 100644
> --- a/gdb/dwarf2/cooked-index.c
> +++ b/gdb/dwarf2/cooked-index.c
> @@ -267,7 +267,7 @@ cooked_index_shard::handle_gnat_encoded_entry (cooked_index_entry *entry,
>     if (canonical.empty ())
>       return {};
>     std::vector<gdb::string_view> names = split_name (canonical.c_str (),
> -						    split_style::DOT);
> +						    split_style::DOT_STYLE);
>     gdb::string_view tail = names.back ();
>     names.pop_back ();
>   
> diff --git a/gdb/split-name.c b/gdb/split-name.c
> index a50a6fa4946..0253b3cf675 100644
> --- a/gdb/split-name.c
> +++ b/gdb/split-name.c
> @@ -58,7 +58,7 @@ split_name (const char *name, split_style style)
>   	}
>         break;
>   
> -    case split_style::DOT:
> +    case split_style::DOT_STYLE:
>         /* D and Go-style names.  */
>         for (const char *iter = strchr (name, '.');
>   	   iter != nullptr;
> diff --git a/gdb/split-name.h b/gdb/split-name.h
> index 47896cc4406..7648cf9b900 100644
> --- a/gdb/split-name.h
> +++ b/gdb/split-name.h
> @@ -30,8 +30,9 @@ enum class split_style
>     NONE,
>     /* C++ style, with "::" and template parameter intelligence.  */
>     CXX,
> -  /* Split at ".".  Used by Ada, Go, D.  */
> -  DOT,
> +  /* Split at ".".  Used by Ada, Go, D.  This has a funny name to work
> +     around a bug in Bison 2.3, which is used on macOS.  */
> +  DOT_STYLE,
>     /* Split at "__".  Used by Ada encoded names.  */
>     UNDERSCORE,
>   };
> diff --git a/gdb/symtab.h b/gdb/symtab.h
> index ca3b1a4a0b6..8f587807ff9 100644
> --- a/gdb/symtab.h
> +++ b/gdb/symtab.h
> @@ -305,7 +305,7 @@ class lookup_name_info final
>   	break;
>         case language_d:
>         case language_go:
> -	style = split_style::DOT;
> +	style = split_style::DOT_STYLE;
>   	break;
>         }
>       return ::split_name (language_lookup_name (lang), style);

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom Tromey]

> What type of tests did you have in mind when you, in a previous mail
> in the same thread, wrote:

>   If the appended works for you (be sure to run some tests), I can check
>   it in.

> Is it sufficient with a simple C project and a simple C++ project (my
> example was using std::vector to get some namespace and template
> expansion) built for arm-none-eabi? Those 2 projects appears to work
> as expected anyway.

Yes, that's plenty, thank you.
I'll check the patch in soon.

Tom

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Torbjorn SVENSSON]

On 2023-09-14 23:32, Tom Tromey wrote:
>> What type of tests did you have in mind when you, in a previous mail
>> in the same thread, wrote:
> 
>>    If the appended works for you (be sure to run some tests), I can check
>>    it in.
> 
>> Is it sufficient with a simple C project and a simple C++ project (my
>> example was using std::vector to get some namespace and template
>> expansion) built for arm-none-eabi? Those 2 projects appears to work
>> as expected anyway.
> 
> Yes, that's plenty, thank you.
> I'll check the patch in soon.
> 
> Tom

Let me know if you want me to push the patch (with you as co-author).

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Tom Tromey]

>> Yes, that's plenty, thank you.
>> I'll check the patch in soon.

Torbjorn> Let me know if you want me to push the patch (with you as co-author).

I did it that day.

Tom

Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

[Torbjorn SVENSSON]

On 2023-09-17 03:21, Tom Tromey wrote:
>>> Yes, that's plenty, thank you.
>>> I'll check the patch in soon.
> 
> Torbjorn> Let me know if you want me to push the patch (with you as co-author).
> 
> I did it that day.
> 
> Tom

Thank you Tom!