Nuo Mi:
> On Mon, Feb 15, 2021 at 3:45 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Nuo Mi:
>>> From: Mark Thompson <s...@jkqxz.net>
>>>
>>>
>>> -}
>>> +static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
>>> + CodedBitstreamUnit *unit)
>>> +{
>>> + typedef struct {
>>> + int nal_unit_type;
>>> + int max_count;
>>> + const char *name;
>>
>> If this were a char name[4], these structs could be put in .rodata
>> instead of .data (or .data.rel.ro) when using position-independent code.
>>
> thanks for the suggestion.
> What's the benifite for this?
> thanks
>
When one uses position-independent code, the static linker does not know
the runtime address of the strings here, because their position is not
known until runtime. Therefore the static linker has to create
relocations for them which means that it tells the runtime linker that
it should patch up the char * pointer above to point to the real
(offsetted) address of the relevant string. For platforms other than
Windows, these relocations are expensive (see [1]) and the resultant
pages are dirty and can't be shared between processes; furthermore this
process isn't done in a lazy manner, so that even someone who never uses
cbs_h2645 (or cbs at all) will have the dirty pages from the above as
soon as libavcodec is loaded.
- Andreas
[1]:
https://chromium.googlesource.com/chromium/src/+/master/docs/native_relocations.md
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
