12:03 a.m.
On Sat, Oct 23, 2021 at 12:01 AM <crash-utility-request(a)redhat.com> wrote:
Date: Fri, 22 Oct 2021 05:20:57 +0000
From: HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
To: Alexander Egorenkov <egorenar(a)linux.ibm.com>
Cc: "Discussion list for crash utility usage, maintenance and
development" <crash-utility(a)redhat.com>
Subject: Re: [Crash-utility] eppic extension doesn't build with recent
master
Message-ID:
<
TYYPR01MB677798CF5C8AF09969686CE9DD809(a)TYYPR01MB6777.jpnprd01.prod.outlook.com
>
Content-Type: text/plain; charset="iso-2022-jp"
-----Original Message-----
> Hello,
>
> i'm trying to build the recent master branch of the crash utility and
> not able to build eppic extension.
Hi Alex,
Thanks for the report, it's the same on my machine, I forgot this..
Seems that it doesn't support gdb-10.2 currently.
I've cc'd Luc, who is its maintainer. Any information about this?
The following patch describes the reason for this change in gdb. It
includes both C and C++ header files in a file simultaneously, which may
trigger the following compilation issues.
...
In file included from ../gdb-10.2/gdb/defs.h:28,
from eppic/applications/crash/eppic.c:22:
../gdb-10.2/gdbsupport/common-defs.h:90:10: fatal error: cstdlib: No such
file or directory
#include <cstdlib>
^~~~~~~~~
compilation terminated.
...
But on the other hand, the eppic also needs to embrace these changes, the
eppic code included some header files, which did not exist in gdb-10.2,
accordingly
it should remove(or change) these header files such as "gdb_string.h" and
"gdb_stat.h".
It looks like an intertwined issue, just providing a clue for this issue.
Subject: [PATCH] gdbsupport: include cstdlib in common-defs.h
In PR 25731 [1], the following build failure was reported:
../../binutils-gdb/gdb/gdbtypes.c:1254:10: error: no member named 'abs'
in namespace 'std'; did you mean simply 'abs'?
= ((std::abs (stride) * element_count) + 7) / 8;
^~~~~~~~
abs
/usr/include/stdlib.h:129:6: note: 'abs' declared here
int abs(int) __pure2;
^
The original report was using:
$ gcc -v
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Note that I was _not_ able to reproduce using:
$ g++ --version
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
The proposed fix is to include <cstdlib> in addition to <stdlib.h>.
Here's an excerpt of [2] relevant to this problem:
These headers [speaking of the .h form] are allowed to also declare
the same names in the std namespace, and the corresponding cxxx
headers are allowed to also declare the same names in the global
namespace: including <cstdlib> definitely provides std::malloc and
may also provide ::malloc. Including <stdlib.h> definitely provides
::malloc and may also provide std::malloc
Since we use std::abs, we should not assume that our include of stdlib.h
declares an `abs` function in the `std` namespace.
If we replace the include of stdlib.h with cstdlib, then we fall in the
opposite situation. A standard C++ library may decide to only put the
declarations in the std namespace, requiring us to prefix all standard
functions with `std::`. I'm not against that, but for the moment I think
the
safest way forward is to just include both.
Note that I don't know what effect this patch can have on any stdlib.h fix
provided by gnulib.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25731
[2] https://en.cppreference.com/w/cpp/header#C_compatibility_headers
gdbsupport/ChangeLog:
* common-defs.h: Include cstdlib.h.
diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
index e42d2b80c045..d3f5eafa4555 100644
--- a/gdbsupport/common-defs.h
+++ b/gdbsupport/common-defs.h
@@ -84,7 +84,12 @@
#include <stdarg.h>
#include <stdio.h>
+
+/* Include both cstdlib and stdlib.h to ensure we have standard functions
+ defined both in the std:: namespace and in the global namespace. */
+#include <cstdlib>
#include <stdlib.h>
+
#include <stddef.h>
#include <stdint.h>
#include <string.h>
--
2.20.1
Thanks,
Kazu
>
> The build failure on x86_64 Fedora 34
> -------------------------------------
>
> $ make lzo
> [snip]
> $ make extensions
> gcc -Wall -g -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86_64
-DLZO -DGDB_10_2
> gcc -Wall -g -shared -rdynamic -o echo.so echo.c -fPIC -DX86_64 -DLZO
-DGDB_10_2
> Cloning into 'eppic'...
> remote: Enumerating objects: 268, done.
> remote: Counting objects: 100% (51/51), done.
> remote: Compressing objects: 100% (44/44), done.
> remote: Total 268 (delta 4), reused 31 (delta 4), pack-reused 217
> Receiving objects: 100% (268/268), 256.48 KiB | 2.49 MiB/s, done.
> Resolving deltas: 100% (93/93), done.
> cd eppic/libeppic && make
> bison -peppic -v -t -d eppic.y
> eppic.y: warning: 253 shift/reduce conflicts [-Wconflicts-sr]
> eppic.y: warning: 20 reduce/reduce conflicts [-Wconflicts-rr]
> eppic.y: note: rerun with option '-Wcounterexamples' to generate
conflict counterexamples
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_util.o eppic_util.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_node.o eppic_node.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_var.o eppic_var.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_func.o eppic_func.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_str.o eppic_str.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_op.o eppic_op.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_num.o eppic_num.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_stat.o eppic_stat.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_builtin.o
eppic_builtin.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_type.o eppic_type.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_case.o eppic_case.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_api.o eppic_api.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_member.o eppic_member.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_alloc.o eppic_alloc.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_define.o eppic_define.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_input.o eppic_input.c
> cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_print.o eppic_print.c
> bison -peppicpp -v -t -d eppicpp.y
> eppicpp.y: warning: 23 shift/reduce conflicts [-Wconflicts-sr]
> eppicpp.y: note: rerun with option '-Wcounterexamples' to generate
conflict counterexamples
> cc -g -fno-omit-frame-pointer -fPIC -c eppicpp.tab.c
> cc -g -fno-omit-frame-pointer -fPIC -c eppic.tab.c
> flex -L -Peppic -t eppic.l > lex.eppic.c
> cc -g -fno-omit-frame-pointer -fPIC -c lex.eppic.c
> flex -Peppicpp -t eppicpp.l > lex.eppicpp.c
> cc -g -fno-omit-frame-pointer -fPIC -c lex.eppicpp.c
> cc -g -fno-omit-frame-pointer -fPIC -o mkbaseop mkbaseop.c
> ./mkbaseop > baseops.c
> cc -g -fno-omit-frame-pointer -fPIC -c baseops.c
> ar cur libeppic.a eppic_util.o eppic_node.o eppic_var.o eppic_func.o
eppic_str.o eppic_op.o eppic_num.o
> eppic_stat.o eppic_builtin.o eppic_type.o eppic_case.o eppic_api.o
eppic_member.o eppic_alloc.o
> eppic_define.o eppic_input.o eppic_print.o eppicpp.tab.o eppic.tab.o
lex.eppic.o lex.eppicpp.o baseops.o
> gcc -g -Ieppic/libeppic -I../gdb-10.2/gdb -I../gdb-10.2/bfd
-I../gdb-10.2/include
> -I../gdb-10.2/gdb/config -I../gdb-10.2/gdb/common -I../gdb-10.2
-nostartfiles -shared -rdynamic -o
> eppic.so eppic/applications/crash/eppic.c -fPIC -DX86_64 -DGDB_10_2
-Leppic/libeppic -leppic
> In file included from ../gdb-10.2/gdb/defs.h:28,
> from eppic/applications/crash/eppic.c:22:
> ../gdb-10.2/gdbsupport/common-defs.h:90:10: fatal error: cstdlib: No
such file or directory
> 90 | #include <cstdlib>
> | ^~~~~~~~~
> compilation terminated.
> make[4]: [eppic.mk:67: eppic.so] Error 1 (ignored)
> gcc -Wall -g -I. -shared -rdynamic -o snap.so snap.c -fPIC -DX86_64
-DLZO -DGDB_10_2
>
------------------------------------------------------------------------------------------------------
> --------
>
>
> Exactly the same problem is occurring on s390 architecture.
>
> I find it's very weird that a C library like eppic is including a C++
> header from GDB.
>
> gdb-10.2/gdbsupport/common-defs.h is a C++ header containing includes of
> other C++ headers like cstdlib, array etc. Furthermore, it contains C++
> templates !
>
> Has anybody tested this ? Maybe i'm doing something wrong :/
> Would appreciate any hint how to fix this. So far i haven't figured out
> howto fix this and we depend on eppic extension.
>
>
> Thanks
> Regards
> Alex