On 15.01.2026 13:30, Matthieu Longo wrote:
> On 15/01/2026 07:27, Jan Beulich wrote:
>> On 14.01.2026 18:49, Matthieu Longo wrote:
>>> The prototype declaration macros currently do not allow functions to be
>>> excluded from the dynamic symbol table. There is an on-going effort in
>>> the bfd library in binutils to reduce the size of the dynamic symbol
>>> table by applying a visibility attribute to non-public symbols declared
>>> in headers.
>>>
>>> The doubly linked list utilities are used in the bfd library, and
>>> therefore need to support passing such a visibility attribute to their
>>> function prototypes. This patch extends the existing DECL macros with
>>> a new ATTRIBUTE parameter.
>>> ---
>>> include/doubly-linked-list.h | 89 ++++++++++---------
>>> libiberty/testsuite/test-doubly-linked-list.c | 4 +-
>>> 2 files changed, 50 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/include/doubly-linked-list.h b/include/doubly-linked-list.h
>>> index 0108af73f96..c9db5220240 100644
>>> --- a/include/doubly-linked-list.h
>>> +++ b/include/doubly-linked-list.h
>>> @@ -30,9 +30,11 @@
>>>
>>> Each function (### is a placeholder for method name) has a macro for:
>>> (1) its invocation LINKED_LIST_###(LTYPE).
>>> - (2) its prototype LINKED_LIST_DECL_###(A, A2, scope). To add in a header
>>> - file, or a source file for forward declaration. 'scope' should be
>>> set
>>> - respectively to 'extern', or 'static'.
>>> + (2) its prototype LINKED_LIST_DECL_###(A, A2, scope, visibility
>>> attribute).
>>
>> If already we add such a parameter (see below as to whether to), let's not
>> limit its potential purpose in the description. I.e. drop "visibility".
>>
>>> + To add in a header file, or a source file for forward declaration.
>>> + 'scope' should be set respectively to 'extern', or 'static'.
>>> + 'visibility attribute' can be used to set a visibility attribute to
>>> + remove the symbol from the dynamic symbol table.
>>> (3) its definition LINKED_LIST_DEFN_###(A, A2, scope). To add in a
>>> source
>>> file with the 'scope' set respectively to nothing, or 'static'
>>> depending
>>> on (2).
>>> @@ -68,9 +70,9 @@
>>> Precondition: prev and next of new_ must be NULL. */
>>> #define LINKED_LIST_APPEND(LTYPE) LTYPE##_append
>>>
>>> -#define LINKED_LIST_DECL_APPEND(LWRAPPERTYPE, LTYPE, EXPORT)
>>> \
>>> +#define LINKED_LIST_DECL_APPEND(LWRAPPERTYPE, LTYPE, EXPORT, ATTRIBUTE)
>>> \
>>
>> Is the extra parameter really needed? Can't the use site of the macro ...
>>
>>> EXPORT void
>>> \
>>
>> ... append (or prepend?) it to what it passes for EXPORT? That may then also
>> allow use of this argument with e.g. MSVC's __declspec() (don't know whether
>> nowadays this is still of interest; it certainly used to be at some point).
>
> If I rephrase your comments above, just to make sure I understood you well,
>
> 1. We should use the same macro parameter to pass the visibility attribute.
> If we want to pass more attributes, it should work as well.
> - If this is correct, I think that the parameter EXPORT should be renamed to
> ATTRIBUTES.
I don't think this is strictly necessary. EXPORT wasn't exactly right for the
present
purpose (imo), and would be good enough to also cover the new one. It is in
particular
an entirely appropriate name for having __declspec(dllexport) passed.
> - If we only plan to pass the scope attribute, i.e. extern, static,
> __declspec(dllexport), __attribute__ ((__visibility__ ("hidden"))), then
> SCOPE would be a better name.
>
> 2. In the binutils codebase, ATTRIBUTE_HIDDEN is normally placed at the end
> of the function declaration.
> However, Visual Studio has some constraints on __declspec.
> https://learn.microsoft.com/en-us/cpp/cpp/declspec?view=msvc-170
>> The __declspec keywords should be placed at the beginning of a simple
>> declaration. The compiler ignores, without warning, any __declspec keywords
>> placed after * or & and in front of the variable identifier in a declaration.
> Consequently, you would prefer that we move the parameter to the beginning of
> the function declaration to make it potentialluy compatible with VS.
I would view this compatibility with VS as an extra benefit, but I wouldn't
base the
decision solely on it. In any event, what exactly to do is mainly to be judged
by the
libiberty maintainer(s).
Jan
