Re: [outcome] Inline GDB pretty printing support

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-07-02 13:37:28

On 02/07/2024 13:09, Julien Blanc via Boost wrote:
> 2 juillet 2024 à 12:58 "Andrey Semashev via Boost" <boost_at_[hidden]> a écrit:
>>
>>
>> Also, on the topic of binary size, is this script embedded into the
>> final binary only once, even if the header is included in multiple TUs?
> 
> That (binary size) was also one of my concern, i checked the following :
> 
> * the whole section is correctly stripped when stripping debug symbols (and correctly preserved in the external debug symbols file)
> * multiple sections works correctly
> * the section is indeed only added once in the final binary
> 
> (for what it's worth, tests done with gcc x64, gcc cross-compiling to arm32 and clang x64, no issues with any of these configurations)

Note that linkers don't have to honour the merge section request if they 
don't want to. Furthermore, some may ignore merging sections of null 
terminated strings, like these.

The merging algorithm which GNU ld seems to use is stick all the 
sections into a hash table keyed by the hash of the section contents, 
thus eliminating all exact duplicates. It then emits an unpredictable 
sequence of appended strings.

You therefore need to be careful that any Python you write can be safely 
#included with any other Python in any arbitrary order. If there is any 
difference at all, that causes a copy to be emitted, so if you ever 
change the string and a user mixes binary versions, you'll get two of 
the visualisers or more. You need to write your visualiser to cope with 
that, too.

I didn't test other linkers apart from ld well, though from first glance 
GNU gold appears to do the right thing. I didn't try other linkers.

Niall