[PATCH] [gdb/build] Work around cgen odr violations

[PATCH] [gdb/build] Work around cgen odr violations

[Tom de Vries]

When building gdb with -flto -O2, I run into:
...
opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
  C++ One Definition Rule [-Wodr]
 typedef enum cgen_operand_type {
              ^
opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
  defined in another translation unit
 typedef enum cgen_operand_type {
              ^
opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
  Definition Rule [-Wodr]
 typedef enum cgen_hw_type {
              ^
opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
  defined in another translation unit
 typedef enum cgen_hw_type {
              ^
...

Fix this by making the conflicting type names unique, adding a target-specific
prefix using a define before the include:
...
 #define cgen_operand_type <target-name>_cgen_operand_type
 #define cgen_hw_type  <target-name>_cgen_hw_type
 #include "opcodes/<target-name>-desc.h"
...

Likewise for targets frv and lm32, the two other targets that include
opcodes/<target-name>-desc.h.

A PR has been filed to take care of this in the opcodes dir instead (PR30758).

Tested on x86_64-linux.

PR build/30757
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757
---
 gdb/frv-tdep.c  | 6 +++++-
 gdb/lm32-tdep.c | 6 +++++-
 gdb/mep-tdep.c  | 5 ++++-
 gdb/or1k-tdep.h | 3 +++
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/gdb/frv-tdep.c b/gdb/frv-tdep.c
index 6c6050a919a..a32071f0395 100644
--- a/gdb/frv-tdep.c
+++ b/gdb/frv-tdep.c
@@ -29,7 +29,6 @@
 #include "dis-asm.h"
 #include "sim-regno.h"
 #include "sim/sim-frv.h"
-#include "opcodes/frv-desc.h"	/* for the H_SPR_... enums */
 #include "symtab.h"
 #include "elf-bfd.h"
 #include "elf/frv.h"
@@ -40,6 +39,11 @@
 #include "objfiles.h"
 #include "gdbarch.h"
 
+/* Make cgen names unique to prevent ODR conflicts with other targets.  */
+#define cgen_operand_type frv_cgen_operand_type
+#define cgen_hw_type frv_cgen_hw_type
+#include "opcodes/frv-desc.h"	/* for the H_SPR_... enums */
+
 struct frv_unwind_cache		/* was struct frame_extra_info */
   {
     /* The previous frame's inner-most stack address.  Used as this
diff --git a/gdb/lm32-tdep.c b/gdb/lm32-tdep.c
index 23998f85dd8..6ab57fde1df 100644
--- a/gdb/lm32-tdep.c
+++ b/gdb/lm32-tdep.c
@@ -32,10 +32,14 @@
 #include "regcache.h"
 #include "trad-frame.h"
 #include "reggroups.h"
-#include "opcodes/lm32-desc.h"
 #include <algorithm>
 #include "gdbarch.h"
 
+/* Make cgen names unique to prevent ODR conflicts with other targets.  */
+#define cgen_operand_type lm32_cgen_operand_type
+#define cgen_hw_type lm32_cgen_hw_type
+#include "opcodes/lm32-desc.h"
+
 /* Macros to extract fields from an instruction.  */
 #define LM32_OPCODE(insn)       ((insn >> 26) & 0x3f)
 #define LM32_REG0(insn)         ((insn >> 21) & 0x1f)
diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c
index fc786f09e44..3484b9bbe0a 100644
--- a/gdb/mep-tdep.c
+++ b/gdb/mep-tdep.c
@@ -47,7 +47,10 @@
 #include "gdbarch.h"
 
 /* Get the user's customized MeP coprocessor register names from
-   libopcodes.  */
+   libopcodes.  Make cgen names unique to prevent ODR conflicts with other
+   targets.  */
+#define cgen_operand_type mep_cgen_operand_type
+#define cgen_hw_type mep_cgen_hw_type
 #include "opcodes/mep-desc.h"
 #include "opcodes/mep-opc.h"
 
diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
index a11950584d7..c1efbc4c3de 100644
--- a/gdb/or1k-tdep.h
+++ b/gdb/or1k-tdep.h
@@ -23,6 +23,9 @@
 #define TARGET_OR1K
 #endif
 
+/* Make cgen names unique to prevent ODR conflicts with other targets.  */
+#define cgen_operand_type or1k_cgen_operand_type
+#define cgen_hw_type or1k_cgen_hw_type
 #include "opcodes/or1k-desc.h"
 #include "opcodes/or1k-opc.h"
 

base-commit: 0c9546b152f6b01756475ce259c895d3fa446774
-- 
2.35.3

Re: [PATCH] [gdb/build] Work around cgen odr violations

[Tom Tromey]

>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:

Tom> When building gdb with -flto -O2, I run into:
Tom> ...
Tom> opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
Tom>   C++ One Definition Rule [-Wodr]
Tom>  typedef enum cgen_operand_type {

I thought... hey, the best way is probably to change cgen to emit
different names for these things.  So I tried looking at cgen.  Then I
found out I don't know how it can even be run at all.  Maybe it requires
the obsolete-and-no-longer-shipped Guile 1.8 -- it definitely barfs with
newer versions.

Tom> Fix this by making the conflicting type names unique, adding a target-specific
Tom> prefix using a define before the include:
Tom> ...
Tom>  #define cgen_operand_type <target-name>_cgen_operand_type
Tom>  #define cgen_hw_type  <target-name>_cgen_hw_type
Tom>  #include "opcodes/<target-name>-desc.h"
Tom> ...

Thanks.

Approved-By: Tom Tromey <tom@tromey.com>

Tom> A PR has been filed to take care of this in the opcodes dir instead (PR30758).

That was WONTFIX'd unfortunately.

Tom

Re: [PATCH] [gdb/build] Work around cgen odr violations

[Tom de Vries]

On 8/18/23 17:46, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Tom> When building gdb with -flto -O2, I run into:
> Tom> ...
> Tom> opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
> Tom>   C++ One Definition Rule [-Wodr]
> Tom>  typedef enum cgen_operand_type {
> 
> I thought... hey, the best way is probably to change cgen to emit
> different names for these things.  So I tried looking at cgen.  Then I
> found out I don't know how it can even be run at all.  Maybe it requires
> the obsolete-and-no-longer-shipped Guile 1.8 -- it definitely barfs with
> newer versions.
> 

Agreed, that's the best way. I decided though to try to achieve that by 
filing the binutils PR, to see if the binutils maintainers could help out.

> Tom> Fix this by making the conflicting type names unique, adding a target-specific
> Tom> prefix using a define before the include:
> Tom> ...
> Tom>  #define cgen_operand_type <target-name>_cgen_operand_type
> Tom>  #define cgen_hw_type  <target-name>_cgen_hw_type
> Tom>  #include "opcodes/<target-name>-desc.h"
> Tom> ...
> 
> Thanks.
> 
> Approved-By: Tom Tromey <tom@tromey.com>
> 

Thanks for the review.

After trying a bit more, with -flto-partitions=one and and various gcc 
version, I found more occurrences so I went the yy-remap.h way in a v2, 
submitted here ( 
https://sourceware.org/pipermail/gdb-patches/2023-August/201719.html ).

I also considered trying to generate a custom -desc.h using sed, which 
would be guaranteed to be complete, but I realized that would also 
require some complex custom solution to skip '#include' and function 
names, so I decided against that.

> Tom> A PR has been filed to take care of this in the opcodes dir instead (PR30758).
> 
> That was WONTFIX'd unfortunately.

Yep, unfortunate indeed.

FWIW, the rationale given there was about libopcodes being a C library, 
and I also briefly considered encapsulating the use of the *-desc.h 
files in a C file, and exporting a cgen-free interface from there, to be 
used in C++ files, but I found that there's no longer any real support 
for compiling C inside the gdb dir.

Thanks,
- Tom

Re: [PATCH] [gdb/build] Work around cgen odr violations

[Tom Tromey]

>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:

>> That was WONTFIX'd unfortunately.

Tom> Yep, unfortunate indeed.

Tom> FWIW, the rationale given there was about libopcodes being a C
Tom> library, and I also briefly considered encapsulating the use of the
Tom> *-desc.h files in a C file, and exporting a cgen-free interface from
Tom> there, to be used in C++ files, but I found that there's no longer any
Tom> real support for compiling C inside the gdb dir.

I didn't look too deeply, but it seems to me that if the types in
question are truly only used by libopcodes -- and never directly
referred to by gdb -- then this would be a -Wodr bug.

OTOH if the types have to be used by library users, then yeah, renaming
is preferable by far.

I don't know which is the case here though.

Tom