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).
>
> 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
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
