Re: [PATCH] Fix C99 compatibility issues in embedded copy of GDB

[lijiang <lijiang@xxxxxxxxxx>]

On Tue, Feb 28, 2023 at 12:33 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab@xxxxxxx> wrote:

On 2023/02/22 16:50, Florian Weimer wrote:
> * HAGIO KAZUHITO(萩尾　一仁):
>
>>> +@@ -123,14 +142,70 @@
>>> + #define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
>>> + #define __bos0(ptr) __builtin_object_size (ptr, 0)
>>> +
>>> ++/* Use __builtin_dynamic_object_size at _FORTIFY_SOURCE=3 when available.  */
>>> ++#if __USE_FORTIFY_LEVEL == 3 && (__glibc_clang_prereq (9, 0)                    \
>>> ++                           || __GNUC_PREREQ (12, 0))
>>> ++# define __glibc_objsize0(__o) __builtin_dynamic_object_size (__o, 0)
>>> ++# define __glibc_objsize(__o) __builtin_dynamic_object_size (__o, 1)
>>> ++#else
>>> ++# define __glibc_objsize0(__o) __bos0 (__o)
>>> ++# define __glibc_objsize(__o) __bos (__o)
>>> ++#endif
>>> ++
>>
>>> ++#if __USE_FORTIFY_LEVEL > 0
>>
>> I could not find this line in the latest GDB source and the related
>> patches.  What is this for?
>
> We need to sync this again with gnulib/GDB.  It was added here, in
> glibc, which is the primary source of this file:

I see, thanks.

>
> commit 2337e04e21ba6040926ec871e403533f77043c40
> Author: Siddhesh Poyarekar <siddhesh@xxxxxxxxxxxxxx>
> Date:   Thu Feb 2 07:49:02 2023 -0500
>
>      cdefs: Limit definition of fortification macros
>     
>      Define the __glibc_fortify and other macros only when __FORTIFY_LEVEL >
>      0.  This has the effect of not defining these macros on older C90
>      compilers that do not have support for variable length argument lists.
>     
>      Also trim off the trailing backslashes from the definition of
>      __glibc_fortify and __glibc_fortify_n macros.
>     
>      Signed-off-by: Siddhesh Poyarekar <siddhesh@xxxxxxxxxxxxxx>
>      Reviewed-by: Florian Weimer <fweimer@xxxxxxxxxx>
>
> I should have made a note that this is coming from the ultimate upstream
> sources.
>
> I raised the issue of <sys/cdefs.h> syncing here:
>
>    Updating <sys/cdefs.h> in glibc and gnulib
>    <https://sourceware.org/pipermail/libc-alpha/2023-February/145758.html>
>
>>> +@@ -134,6 +136,7 @@ typedef int (*_bashfunc)(const char *, ...);
>>> + #else
>>> + typedef int (*_bashfunc)();
>>> + #endif
>>> ++#include <stdlib.h>
>>> + main()
>>
>> The GDB patch b4f26d541aa7 ("Import GNU Readline 8.1") has the
>> following:
>>
>> @@ -134,6 +138,8 @@ typedef int (*_bashfunc)(const char *, ...);
>>    #else
>>    typedef int (*_bashfunc)();
>>    #endif
>> +#include <stdlib.h>
>> +int
>>    main()
>>    {
>>    _bashfunc pf;
>>
>> Isn't this "int" needed?
>
> It is, but this part is not actually used (the file is more of a macro
> library for bash, I guess, and the use in readline is merely an
> afterthought).
>

I also have similar concerns. Some upstream changes are not included in this patch, and

these functions are in the current gdb-10.2, for example:

...

--- a/readline/readline/aclocal.m4
+++ b/readline/readline/aclocal.m4

@@ -321,6 +334,9 @@ AC_CACHE_VAL(bash_cv_opendir_not_robust,
 #ifdef HAVE_UNISTD_H
 # include <unistd.h>
 #endif /* HAVE_UNISTD_H */
+#ifdef HAVE_SYS_STAT_H
+#include <sys/stat.h>
+#endif
 #if defined(HAVE_DIRENT_H)
 # include <dirent.h>
 #else
...
@@ -300,7 +312,8 @@ AC_DEFUN(BASH_FUNC_STRSIGNAL,
 [AC_MSG_CHECKING([for the existence of strsignal])
 AC_CACHE_VAL(bash_cv_have_strsignal,
 [AC_TRY_LINK([#include <sys/types.h>
-#include <signal.h>],
+#include <signal.h>
+#include <string.h>],
 [char *s = (char *)strsignal(2);],
  bash_cv_have_strsignal=yes, bash_cv_have_strsignal=no)])
 AC_MSG_RESULT($bash_cv_have_strsignal)
...
@@ -684,6 +706,11 @@ AC_DEFUN(BASH_FUNC_ULIMIT_MAXFDS,
 [AC_MSG_CHECKING(whether ulimit can substitute for getdtablesize)
 AC_CACHE_VAL(bash_cv_ulimit_maxfds,
 [AC_TRY_RUN([
+#include <stdlib.h>
+#ifdef HAVE_ULIMIT_H
+#include <ulimit.h>
+#endif
+int

In addition, for the readline part, in fact some early crash distributions used the

system readline library, and enabled the feature with the option "--with-system-readline"

in the crash tool.

The advantages are that there are few changes in crash gdb-10.2.patch and can use new

features in the readline library, which can be easy to update in the system.

The disadvantage is that crash may not be compatible with the system readline library and

need depend on the system readline library.

The current crash-utility is using the embedded readline lib in gdb, maybe we also have to

face the future changes. This may come with a trade-off. 

> The problem is that the upstream patch does not really apply to the GDB
> 10.2 sources.  None of this work is really forward-looking, given that
> crash will eventually have to import a newer GDB version.

True, but there is no plan to update the embedded GDB for now and it
would be better to sync with the upstream code just in case, so I've
updated some hunks like so.  Does the attached patch work for you? 

Lianbo, I've changed the diff headers as you said, could you check
and test this?

 

With the attached patch, the test passed. But I still suggest some minor modifications:

[1] add related upstream commits(gnulib/GDB and glibc) to patch log

[2] no need to add new files at the end of "tar xvzmf gdb-10.2.tar.gz" this time

 

$ grep ^+++ gdb-10.2.patch | sort | uniq -c
      1 +++ gdb-10.2/bfd/elf-bfd.h
      1 +++ gdb-10.2/gdb/ada-lang.c
      1 +++ gdb-10.2/gdb/cli/cli-cmds.c
      1 +++ gdb-10.2/gdb/completer.c
      1 +++ gdb-10.2/gdb/c-typeprint.c
      1 +++ gdb-10.2/gdb/defs.h
      1 +++ gdb-10.2/gdb/dwarf2/read.c
      1 +++ gdb-10.2/gdb/gdbtypes.c
      1 +++ gdb-10.2/gdb/main.c
      2 +++ gdb-10.2/gdb/Makefile.in
      1 +++ gdb-10.2/gdb/objfiles.h
      2 +++ gdb-10.2/gdb/printcmd.c
      1 +++ gdb-10.2/gdb/psymtab.c
      2 +++ gdb-10.2/gdb/symfile.c
      3 +++ gdb-10.2/gdb/symtab.c
      1 +++ gdb-10.2/gdb/ui-file.h
      1 +++ gdb-10.2/gdb/xml-syscall.c
      1 +++ gdb-10.2/gnulib/import/cdefs.h
      1 +++ gdb-10.2/libiberty/aclocal.m4
      1 +++ gdb-10.2/libiberty/configure
      1 +++ gdb-10.2/libiberty/Makefile.in
      1 +++ gdb-10.2/Makefile.in
      1 +++ gdb-10.2/opcodes/i386-dis.c
      1 +++ gdb-10.2/readline/readline/aclocal.m4
      1 +++ gdb-10.2/readline/readline/configure
      1 +++ gdb-10.2/readline/readline/configure.ac
      1 +++ gdb-10.2/readline/readline/misc.c
      1 +++ gdb-10.2/readline/readline/readline.h
      1 +++ gdb-10.2/readline/readline/rltypedefs.h
      1 +++ gdb-10.2/readline/readline/util.c

Thanks.

Lianbo

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki