[Bug binutils/30758] ODR violations in opcodes dir
https://sourceware.org/bugzilla/show_bug.cgi?id=30758
Tom de Vries changed:
What|Removed |Added
Blocks|22395 |
Severity|normal |enhancement
--- Comment #6 from Tom de Vries ---
(In reply to Alan Modra from comment #5)
> I'm guessing that it is the use of opcodes cgen headers in gdb itself that
> is triggering these warnings, not the use of those headers in opcodes. I
> think I'd be looking at gdb/mep-tdep.c and gdb/or1k-tdep.c, perhaps trying
> to replace use of cgen types in structs defined there by void*. Does it
> even make sense for g++ to complain about odr violations in extern "C"
> headers?
Thanks for the suggestion.
I went looking in this direction, and came across this doc (
https://en.cppreference.com/w/cpp/language/definition ) where it's suggested to
use unnamed namespaces to work around odr problems with types.
And indeed, this patch fixes the warnings:
...
diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c
index fc786f09e44..8de2c588bad 100644
--- a/gdb/mep-tdep.c
+++ b/gdb/mep-tdep.c
@@ -48,8 +48,10 @@
/* Get the user's customized MeP coprocessor register names from
libopcodes. */
+namespace {
#include "opcodes/mep-desc.h"
#include "opcodes/mep-opc.h"
+}
/* The gdbarch_tdep structure. */
diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
index a11950584d7..b6ec91ab38e 100644
--- a/gdb/or1k-tdep.h
+++ b/gdb/or1k-tdep.h
@@ -23,8 +23,10 @@
#define TARGET_OR1K
#endif
+namespace {
#include "opcodes/or1k-desc.h"
#include "opcodes/or1k-opc.h"
+}
/* General Purpose Registers */
#define OR1K_ZERO_REGNUM 0
...
That's a fix on the gdb side. So I guess this PR on the opcodes side is about
making that patch unnecessary, which would AFAIU involve generating uniquely
named types in cgen.
Of course, this PR could be closed as resolved-wontfix or some such if that's
deemed not a good idea or unnecessary.
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=22395
[Bug 22395] ODR violations
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30758] ODR violations in opcodes dir
https://sourceware.org/bugzilla/show_bug.cgi?id=30758
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> ...
> diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c
> index fc786f09e44..8de2c588bad 100644
> --- a/gdb/mep-tdep.c
> +++ b/gdb/mep-tdep.c
> @@ -48,8 +48,10 @@
>
> /* Get the user's customized MeP coprocessor register names from
> libopcodes. */
> +namespace {
> #include "opcodes/mep-desc.h"
> #include "opcodes/mep-opc.h"
> +}
>
>
>
> /* The gdbarch_tdep structure. */
> diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
> index a11950584d7..b6ec91ab38e 100644
> --- a/gdb/or1k-tdep.h
> +++ b/gdb/or1k-tdep.h
> @@ -23,8 +23,10 @@
> #define TARGET_OR1K
> #endif
>
> +namespace {
> #include "opcodes/or1k-desc.h"
> #include "opcodes/or1k-opc.h"
> +}
>
> /* General Purpose Registers */
> #define OR1K_ZERO_REGNUM 0
> ...
Hmm, that build ok with gcc 7.5.0, but when trying again with gcc 12.3.0, I
get:
...
opcodes/mep-opc.h:59: warning: type of 'mep_config_map' does not match original
declaration [-Wlto-type-mismatch]
59 | extern mep_config_map_struct mep_config_map[];
|
opcodes/mep-opc.h:57: note: type 'struct mep_config_map_struct' defined in
anonymous namespace cannot match type 'struct mep_config_map_struct' across the
translation unit boundary
57 | } mep_config_map_struct;
|
opcodes/mep-opc.c:92: note: the incompatible type defined in another
translation unit
92 | mep_config_map_struct mep_config_map[] =
|
opcodes/mep-opc.c:92: note: 'mep_config_map' was previously declared here
opcodes/mep-opc.c:92: note: code may be misoptimized unless
'-fno-strict-aliasing' is used
...
Now also mep-opc.c is involved.
I'm not sure if the warning makes sense, but I imagine doing the unnamed
namespace trick in the opcodes headers alongside the extern "C" stuff would fix
this.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30758] ODR violations in opcodes dir
https://sourceware.org/bugzilla/show_bug.cgi?id=30758 --- Comment #8 from Tom de Vries --- (In reply to Tom de Vries from comment #7) > I'm not sure if the warning makes sense, but I imagine doing the unnamed > namespace trick in the opcodes headers alongside the extern "C" stuff would > fix this. It doesn't, and besides that it's an anti-pattern ( https://rules.sonarsource.com/cpp/RSPEC-1000/ ). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30758] ODR violations in opcodes dir
https://sourceware.org/bugzilla/show_bug.cgi?id=30758 --- Comment #9 from Tom de Vries --- (In reply to Tom de Vries from comment #7) > Hmm, that build ok with gcc 7.5.0, but when trying again with gcc 12.3.0, I > get: Same with gcc 13.1.1. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30725] severe objdump performance regression
https://sourceware.org/bugzilla/show_bug.cgi?id=30725 --- Comment #3 from Achim --- No, the debuginfod is not enabled and the option has no effect other than a warning about E being an unrecognized debug letter option. Again, both extracting the line number information from the DWARF5 section and the disassembly alone doesn't produce anthing that looks unusual in terms of runtime. Disassembly runtime scales almost lineraly with amount of I/O, DWARF5 record extraction (which must do a fair bit of interpretation of the records I assume rather seems to scale roughly linearly by number of records. objdump 2.41-3 -d -l gcc-ar.exe 0.031u 0.062s 0:00.08 112.5% 0+0k 0+0io 3332pf+0w gcc-ranlib.exe 0.031u 0.000s 0:00.06 50.0% 0+0k 0+0io 3332pf+0w gcc-nm.exe 0.046u 0.015s 0:00.07 71.4% 0+0k 0+0io 3344pf+0w gcov-dump.exe 2.125u 0.046s 0:02.24 96.4% 0+0k 0+0io 4695pf+0w gcov.exe 2.765u 0.000s 0:02.97 92.9% 0+0k 0+0io 7077pf+0w collect2.exe 2.953u 0.000s 0:03.26 90.4% 0+0k 0+0io 4746pf+0w gcov-tool.exe 3.078u 0.031s 0:03.09 100.3% 0+0k 0+0io 4714pf+0w gnatkr.exe 4.218u 0.030s 0:04.31 98.3% 0+0k 0+0io 8583pf+0w gnatlink.exe 4.374u 0.000s 0:04.49 97.3% 0+0k 0+0io 9394pf+0w gnat.exe 4.406u 0.015s 0:04.54 97.1% 0+0k 0+0io 8995pf+0w lto-wrapper.exe4.718u 0.015s 0:04.96 95.1% 0+0k 0+0io 6682pf+0w gnatfind.exe 4.859u 0.046s 0:05.09 96.0% 0+0k 0+0io 10604pf+0w gnatxref.exe 4.984u 0.031s 0:05.32 94.1% 0+0k 0+0io 10596pf+0w gnatchop.exe 5.125u 0.030s 0:05.22 98.6% 0+0k 0+0io 10846pf+0w gnatclean.exe 5.828u 0.031s 0:06.14 95.2% 0+0k 0+0io 14015pf+0w gnatname.exe 5.968u 0.061s 0:06.18 97.4% 0+0k 0+0io 13581pf+0w gnatprep.exe 6.093u 0.000s 0:06.19 98.3% 0+0k 0+0io 14091pf+0w gnatls.exe 6.187u 0.000s 0:06.39 96.7% 0+0k 0+0io 14690pf+0w gnatmake.exe 6.281u 0.031s 0:06.76 93.3% 0+0k 0+0io 15692pf+0w gfortran.exe 6.593u 0.015s 0:06.98 94.5% 0+0k 0+0io 6736pf+0w cpp.exe6.703u 0.000s 0:06.97 96.1% 0+0k 0+0io 6731pf+0w gdc.exe7.000u 0.030s 0:07.00 100.4% 0+0k 0+0io 6735pf+0w gnatbind.exe 13.406u 0.000s 0:13.88 96.5% 0+0k 0+0io 7892pf+0w lto-dump.exe1764.452u 7.656s 32:35.54 90.6% 0+0k 0+0io 34002pf+0w lto1.exe1799.812u 7.406s 33:06.78 90.9% 0+0k 0+0io 34351pf+0w f951.exe2075.375u 6.562s 37:54.62 91.5% 0+0k 0+0io 35373pf+0w cc1.exe 2105.890u 7.593s 38:24.45 91.7% 0+0k 0+0io 34919pf+0w gnat1.exe 2281.406u 6.656s 41:16.20 92.4% 0+0k 0+0io 36665pf+0w d21.exe 2320.968u 8.031s 42:03.11 92.3% 0+0k 0+0io 36393pf+0w cc1plus.exe 2322.546u 7.812s 42:01.87 92.4% 0+0k 0+0io 37496pf+0w cc1objplus.exe 2398.765u 7.859s 43:19.73 92.5% 0+0k 0+0io 37661pf+0w objdump 2.41-3 -d gcc-ar.exe 0.015u 0.000s 0:00.03 33.3% 0+0k 0+0io 3388pf+0w 5523 gcc-ranlib.exe 0.015u 0.015s 0:00.03 66.6% 0+0k 0+0io 3387pf+0w 5523 gcc-nm.exe 0.031u 0.015s 0:00.03 133.3% 0+0k 0+0io 3389pf+0w 5523 gcov-dump.exe 0.484u 0.000s 0:00.60 80.0% 0+0k 0+0io 3966pf+0w 143895 collect2.exe 0.546u 0.000s 0:00.68 79.4% 0+0k 0+0io 4012pf+0w 160080 gcov-tool.exe 0.546u 0.000s 0:00.62 87.0% 0+0k 0+0io 3997pf+0w 150923 cpp.exe0.703u 0.015s 0:01.02 69.6% 0+0k 0+0io 4494pf+0w 241130 lto-wrapper.exe0.796u 0.000s 0:00.89 88.7% 0+0k 0+0io 4426pf+0w 218062 gfortran.exe 0.875u 0.062s 0:00.98 94.8% 0+0k 0+0io 4487pf+0w 241676 gcov.exe 0.890u 0.015s 0:00.89 101.1% 0+0k 0+0io 4780pf+0w 218018 gdc.exe0.921u 0.015s 0:00.98 94.8% 0+0k 0+0io 4488pf+0w 241859 gnatkr.exe 0.936u 0.000s 0:01.00 93.0% 0+0k 0+0io 4638pf+0w 244411 gnat.exe 0.953u 0.015s 0:01.03 93.2% 0+0k 0+0io 4694pf+0w 259251 gnatlink.exe 1.015u 0.030s 0:01.11 93.6% 0+0k 0+0io 4759pf+0w 274573 gnatxref.exe 1.187u 0.030s 0:01.30 93.0% 0+0k 0+0io 4866pf+0w 328849 gnatfind.exe 1.218u 0.015s 0:01.27 96.0% 0+0k 0+0io 4871pf+0w 329068 gnatchop.exe 1.437u 0.000s 0:01.33 107.5% 0+0k 0+0io 4894pf+0w 334560 gnatprep.exe 1.625u 0.015s 0:01.83 89.0% 0+0k 0+0io 5393pf+0w 467170 gnatclean.exe 1.703u 0.015s 0:01.82 93.9% 0+0k 0+0io 5389pf+0w 464192 gnatname.exe 1.718u 0.031s 0:01.76 98.8% 0+0k 0+0io 5325pf+0w 447727 gnatls.exe 1.843u 0.000s 0:01.96 93.8% 0+0k 0+0io 5473pf+0w 491418 gnatbind.exe 1.984u 0.015s 0:02.23 89.2% 0+0k 0+0io 5506pf+0w 563078 gnatmake.exe 2.046u 0.015s 0:02.09 98.0% 0+0k 0+0io 5585pf+0w 447727 lto-dump.exe 15.359u 0.015s 0:16.16 95.0% 0+0k 0+0io 30823pf+0w 6836384 lto1.exe 15.390u 0.046s 0:16.41 94.0% 0+0k 0+0io 30811pf+0w 6836218 cc1.exe 16.562u 0.078s 0:17.90 92.9% 0+0k 0+0io 31598pf+0w 7102189 d21.exe 17.265u 0.156s 0:18.38 94.7% 0+0k 0+0io 32801pf+0w
[Bug ld/30724] cygwin ld performance regression since 014a602b86
https://sourceware.org/bugzilla/show_bug.cgi?id=30724 --- Comment #13 from Achim --- Thank you. Going forward I'd suggest you revisit why you need to turn around the same stream and if it might not be more efficient to just have a read and a write stream (really just append I assume) to the same file and a read barrier that follows the write pointer when flushed. -- You are receiving this mail because: You are on the CC list for the bug.
