On Sat, Oct 23, 2021 at 12:01 AM <crash-utility-request@redhat.com> wrote:
Date: Fri, 22 Oct 2021 05:20:57 +0000
From: HAGIO KAZUHITO(?????)     <k-hagio-ab@nec.com>
To: Alexander Egorenkov <egorenar@linux.ibm.com>
Cc: "Discussion list for crash utility usage,   maintenance and
        development" <crash-utility@redhat.com>
Subject: Re: [Crash-utility] eppic extension doesn't build with recent

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;
    /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


* 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>


> 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