[Crash-utility] [PATCH] Fix C99 compatibility issues in embedded copy of GDB

[lijiang]

On Tue, Feb 28, 2023 at 12:33 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at nec.com>
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 at sourceware.org>
> > 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 at sourceware.org>
> >      Reviewed-by: Florian Weimer <fweimer at redhat.com>
> >
> > 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).
> >
> > 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?
>
>
Yes. I'm testing the patch this week.

Thank you, Kazu and Florian.

Lianbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20230228/d6ab30d9/attachment.htm>