Re: [PATCH] gdb/python/python-internal.h: avoid uninitialized constexpr

[Lancelot SIX <Lancelot.Six@amd.com>]

On 19/06/2024 01:11, Tom Tromey wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
>>>>>> "Lancelot" == Lancelot SIX <Lancelot.Six@amd.com> writes:
> 
> Lancelot> That works with GCC, but still fails with Clang.  I still have
> Lancelot> duplicate symbol errors (both at -O0 and -O3).  My understanding is
> Lancelot> that the compiler can still handle constexr as const if it wants, so
> Lancelot> marking those symbols constexpr will not necessarily prevent them from
> Lancelot> being materialized in the binary.
> 
> Which symbol is duplicate?

All the specialized instantiations appear as duplicates.

With your solution, if I compile with GCC, I have:

$ nm -C gdb/python/py-arch.o|grep gdbpy_method_format
0000000000000380 r gdbpy_method_format<int>
00000000000003c0 r gdbpy_method_format<unsigned int>
0000000000000300 r gdbpy_method_format<long long>
0000000000000340 r gdbpy_method_format<unsigned long long>

while when compiling with clang:

$ nm -C gdb/python/py-arch.o|grep gdbpy_method_format
0000000000000040 R gdbpy_method_format<int>
0000000000000060 R gdbpy_method_format<unsigned int>
0000000000000000 R gdbpy_method_format<long long>
0000000000000020 R gdbpy_method_format<unsigned long long>

It looks like clang picks the "extern" qualifier from the 
non-specialized case, and applies it to all the specializations.

It seems I can avoid this by marking the specializations as inline, i.e.

template<typename T>
extern char gdbpy_method_format;

template<>
constexpr inline char gdbpy_method_format<gdb_py_longest> = 
GDB_PY_LL_ARG[0];

...

This approach seems to work for both clang and gcc.  I can modify my 
patch to use this method if you prefer.

> 
> Anyway if that is the case, then why does your patch work?
> 

In my approach, it seems the symbol is not be present in the object 
files for neither gcc or clang.  If I force it (by taking the address of 
the symbol for example), nm reports the symbol as a weak object ("V") 
for clang and "u" for gcc.

Best,
Lancelot.