[Crash-utility] eppic extension doesn't build with recent
lijiang
lijiang at redhat.com
Tue Nov 16 06:03:53 UTC 2021
On Sat, Oct 23, 2021 at 12:01 AM <crash-utility-request at redhat.com> wrote:
> Date: Fri, 22 Oct 2021 05:20:57 +0000
> From: HAGIO KAZUHITO(?????) <k-hagio-ab at nec.com>
> To: Alexander Egorenkov <egorenar at linux.ibm.com>
> Cc: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility at redhat.com>
> Subject: Re: [Crash-utility] eppic extension doesn't build with recent
> master
> Message-ID:
> <
> TYYPR01MB677798CF5C8AF09969686CE9DD809 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20211116/5d4947f1/attachment.htm>
More information about the Crash-utility
mailing list