* [PATCH] [gdb/build] Work around cgen odr violations
@ 2023-08-18 8:38 Tom de Vries
2023-08-18 15:46 ` Tom Tromey
0 siblings, 1 reply; 4+ messages in thread
From: Tom de Vries @ 2023-08-18 8:38 UTC (permalink / raw)
To: gdb-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] [gdb/build] Work around cgen odr violations
2023-08-18 8:38 [PATCH] [gdb/build] Work around cgen odr violations Tom de Vries
@ 2023-08-18 15:46 ` Tom Tromey
2023-08-21 6:05 ` Tom de Vries
0 siblings, 1 reply; 4+ messages in thread
From: Tom Tromey @ 2023-08-18 15:46 UTC (permalink / raw)
To: Tom de Vries via Gdb-patches; +Cc: Tom de Vries
>>>>> "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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] [gdb/build] Work around cgen odr violations
2023-08-18 15:46 ` Tom Tromey
@ 2023-08-21 6:05 ` Tom de Vries
2023-08-22 15:54 ` Tom Tromey
0 siblings, 1 reply; 4+ messages in thread
From: Tom de Vries @ 2023-08-21 6:05 UTC (permalink / raw)
To: Tom Tromey, Tom de Vries via Gdb-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] [gdb/build] Work around cgen odr violations
2023-08-21 6:05 ` Tom de Vries
@ 2023-08-22 15:54 ` Tom Tromey
0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2023-08-22 15:54 UTC (permalink / raw)
To: Tom de Vries via Gdb-patches; +Cc: Tom Tromey, Tom de Vries
>>>>> "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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-22 18:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-18 8:38 [PATCH] [gdb/build] Work around cgen odr violations Tom de Vries
2023-08-18 15:46 ` Tom Tromey
2023-08-21 6:05 ` Tom de Vries
2023-08-22 15:54 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).