Re: [PATCH] Fix #27777 - now use a doubly-linked list for _IO_list_all

[Florian Weimer <fweimer@redhat.com>]

* alexandre ferrieux:

> On 26/04/2024 19:51, Florian Weimer wrote:
>> * alexandre ferrieux:
>> 
>>> diff --git a/libio/bits/types/struct_FILE.h b/libio/bits/types/struct_FILE.h
>>> index 7cdaae86f8..daebd6ce0a 100644
>>> --- a/libio/bits/types/struct_FILE.h
>>> +++ b/libio/bits/types/struct_FILE.h
>>> @@ -67,7 +67,7 @@ struct _IO_FILE
>>>     struct _IO_marker *_markers;
>>>  -  struct _IO_FILE *_chain;
>>> +  struct _IO_FILE *_chain,**_prevchain;
>>>     int _fileno;
>>>    int _flags2;
>> Unfortunately, this struct is part of the ABI for several reasons.
>> For
>> example, _IO_2_1_stdin_ is a global variable exported by libc.so.6, and
>> it has a struct _IO_FILE member.  It cannot change size due to copy
>> relocations, even if nothing accesses members after _chain.
>> I disagree with H.J.'s suggestion that the answer is symbol
>> versions. 8-)
>
> Interesting !
>
> So we are in the presence of software that can no longer change, _ever_ ?
> What about bumping to _IO_2_2 ?

That requires specific code paths to deal with the earlier versions.

>> Two options come to my mind: Use the FILE * value itself as a hash table
>> key (and use _chain for resolving bucket conflicts), or use a dynarray
>> and replace _chain with a union of a pointer and an unsigned int,
>> containing the dynarray index for that particular file.  The latter has
>> the advantage that we can use it to implement arbitrary extensions in
>> the future.  Either approach should preserve compatibility with GCC 2.95
>> libstdc++ if we are a bit careful.
>
> Argggh. Jumping through complex, inefficient and hard-to-maintain hoops,
> because a fundamentally opaque type has been inadvertently exposed ?

The approaches I mention have the advantage that they work for both
glibc 2.0 and glibc 2.1 (current) file streams, using the same code,
which simplifies testing.

If you want to work on hiding the internals of struct _IO_FILE, that
would be very welcome, but it's a much larger project than fixing this
particular performance issue.

Thanks,
Florian