Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] libavutil: Add av_visibility_hidden for setting hidden symbol visibility
Date: Mon, 11 Jul 2022 18:57:27 +0200
Message-ID: <DB6PR0101MB221475041F14C355E04711608F879@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <2eae56c8-3d9b-c2dc-d669-2f56e1ee3a31@rothenpieler.org>

Timo Rothenpieler:
> On 11.07.2022 16:26, Andreas Rheinhardt wrote:
>> Henrik Gramner:
>>> On Mon, Jul 11, 2022 at 11:19 AM Martin Storsjö <martin@martin.st>
>>> wrote:
>>>> +#if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) &&
>>>> (defined(__ELF__) || defined(__MACH__))
>>>> +#    define av_visibility_hidden __attribute__((visibility("hidden")))
>>>> +#else
>>>> +#    define av_visibility_hidden
>>>> +#endif
>>>
>>> The usual approach is to compile with -fvisibility=hidden and
>>> explicitly flag exported API symbols.
>>>
>>> Is there a reason for doing this the other way around?
>>
>> -fvisibility=hidden only affects the visibility of symbols defined in
>> the currently compiled translation unit. It does not allow the compiler
>> to make assumptions about external declarations that are used in this
>> translation unit (in other words, it has to presume the worst: That it
>> comes from a different DSO). E.g. this is ff_rdft_end on 32bit x86 if
>> ff_fft_end is declared with an explicit hidden attribute:
>>
>> 000000bb <ff_rdft_end>:
>>
>>    bb:    83 44 24 04 18           addl   $0x18,0x4(%esp)
>>
>>    c0:    e9 fc ff ff ff           jmp    c1 <ff_rdft_end+0x6>
>>
>>             c1: R_386_PC32    ff_fft_end
>>
>>
>> And this is the same function if one uses -fvisibility=hidden instead of
>> the attribute:
>>
>> 000000bb <ff_rdft_end>:
>>
>>    bb:    53                       push   %ebx
>>
>>    bc:    e8 fc ff ff ff           call   bd <ff_rdft_end+0x2>
>>
>>             bd: R_386_PC32    __x86.get_pc_thunk.bx
>>
>>    c1:    81 c3 02 00 00 00        add    $0x2,%ebx
>>
>>             c3: R_386_GOTPC    _GLOBAL_OFFSET_TABLE_
>>
>>    c7:    83 ec 14                 sub    $0x14,%esp
>>
>>    ca:    8b 44 24 1c              mov    0x1c(%esp),%eax
>>
>>    ce:    83 c0 18                 add    $0x18,%eax
>>
>>    d1:    50                       push   %eax
>>
>>    d2:    e8 fc ff ff ff           call   d3 <ff_rdft_end+0x18>
>>
>>             d3: R_386_PLT32    ff_fft_end
>>
>>    d7:    83 c4 18                 add    $0x18,%esp
>>
>>    da:    5b                       pop    %ebx
>>
>>    db:    c3                       ret
>>
>>
>> The code is the same as if one had not used -fvisibility=hidden at all.
>>
>> Of course, adding the attribute to every function/object is way too much
>> effort; that's why the pragma exists.
> 
> Is this still true if you also add -fno-semantic-interposition?

Why should that change anything here? It just means that the compiler
may inline functions even though they could potentially be interposed.
But of course the compiler can't inline functions whose definition it
can't see.
Anyway, I tested it and there is no change.

- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2022-07-11 16:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11  9:18 Martin Storsjö
2022-07-11  9:18 ` [FFmpeg-devel] [PATCH 2/2] libavcodec: Set hidden visibility on global symbols accessed from AArch64 assembly Martin Storsjö
2022-07-11 10:58   ` Andreas Rheinhardt
2022-07-11 10:20 ` [FFmpeg-devel] [PATCH 1/2] libavutil: Add av_visibility_hidden for setting hidden symbol visibility Andreas Rheinhardt
2022-07-11 10:40   ` Martin Storsjö
2022-07-11 10:57     ` Andreas Rheinhardt
2022-07-13 11:27     ` Anton Khirnov
2022-07-11 12:12 ` Henrik Gramner
2022-07-11 12:32   ` Triang3l
2022-07-11 14:26   ` Andreas Rheinhardt
2022-07-11 16:51     ` Timo Rothenpieler
2022-07-11 16:57       ` Andreas Rheinhardt [this message]
2022-07-11 21:41   ` Martin Storsjö
2022-07-11 21:42     ` Martin Storsjö

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR0101MB221475041F14C355E04711608F879@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com \
    --to=andreas.rheinhardt@outlook.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git