Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support compiling with -fvisibility=hidden #435

Open
1 of 2 tasks
ayrtonm opened this issue Oct 7, 2024 · 0 comments
Open
1 of 2 tasks

Support compiling with -fvisibility=hidden #435

ayrtonm opened this issue Oct 7, 2024 · 0 comments
Assignees
@kkysen

Comments

@ayrtonm
Copy link
Contributor

ayrtonm commented Oct 7, 2024 •
edited by kkysen
Loading

Split into:

Compiling with -fvisibility=hidden gives the following error which @kkysen hit with dav1d. This is caused because the undefined references become local symbols in the other .so so we need explicit visibility attributes on those variables to avoid this.

[7/7] Linking C executable tests/two_keys_minimal/two_keys_minimal
FAILED: tests/two_keys_minimal/two_keys_minimal
cd /home/ayrton/immunant/IA2-Phase2/build/tests/two_keys_minimal && /usr/bin/objcopy --redefine-syms=/home/ayrton/immunant/IA2-Phase2/build/tests/two_keys_minimal/two_keys_minimal_call_gates_1.objcopy /home/ayrton/immunant/IA2-Phase2/build/tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/./main.c.o && cd /home/ayrton/immunant/IA2-Phase2/build && /usr/bin/cc  -fsanitize=undefined -Wl,--export-dynamic -Wl,@/home/ayrton/immunant/IA2-Phase2/build/tests/two_keys_minimal/two_keys_minimal_call_gates_1.ld -Wl,--print-map-locals -pthread -Wl,--wrap=pthread_create -Wl,--wrap=main -Wl,-z,now -Wl,-z,relro -Wl,-T/home/ayrton/immunant/IA2-Phase2/build/runtime/libia2/padding.ld -Wl,--dynamic-list=/home/ayrton/immunant/IA2-Phase2/build/runtime/libia2/dynsym.syms -Wl,-wrap,calloc -Wl,-wrap,free -Wl,-wrap,malloc -Wl,-wrap,memalign -Wl,-wrap,posix_memalign -Wl,-wrap,pvalloc -Wl,-wrap,realloc -Wl,-wrap,valloc -Wl,-wrap,malloc_usable_size -Wl,-wrap,realpath -Wl,-wrap,strdup -Wl,-wrap,strndup -Wl,-wrap,getcwd -Wl,-wrap,asprintf -Wl,-wrap,vasprintf tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o -o tests/two_keys_minimal/two_keys_minimal  -Wl,-rpath,/home/ayrton/immunant/IA2-Phase2/build/runtime/partition-alloc:/home/ayrton/immunant/IA2-Phase2/build/tests/two_keys_minimal:/home/ayrton/immunant/IA2-Phase2/build/runtime/libia2  -ldl  runtime/libia2/liblibia2.a  runtime/partition-alloc/libpartition-alloc.so  -lcriterion  tests/two_keys_minimal/libtwo_keys_minimal_lib.so  tests/two_keys_minimal/libtwo_keys_minimal_call_gates.so  runtime/libia2/liblibia2.a  -ldl  runtime/libia2/libc.so.6 && :
/usr/bin/ld: tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o: in function `ia2_stackptr_for_pkru':
main.c:(.text+0x24e): undefined reference to `ia2_stackptr_2'
/usr/bin/ld: tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o: in function `init_stacks_and_setup_tls':
main.c:(.text+0x2bf): undefined reference to `init_tls_2'
/usr/bin/ld: main.c:(.text+0x2d0): undefined reference to `ia2_stackptr_2'
/usr/bin/ld: tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o: in function `ia2_init':
main.c:(.text+0x395): undefined reference to `ia2_setup_destructors_2'
/usr/bin/ld: tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o: in function `print_message':
main.c:(.text+0x17fd): undefined reference to `plugin_secret'
/usr/bin/ld: tests/two_keys_minimal/two_keys_minimal: hidden symbol `two_keys_plugin_impl' in tests/two_keys_minimal/CMakeFiles/two_keys_minimal.dir/main.c.o is referenced by DSO
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
@kkysen kkysen self-assigned this Oct 8, 2024
This was referenced Oct 13, 2024
Closed
Open
ayrtonm added a commit that referenced this issue Oct 17, 2024
@ayrtonm
rewriter: Define call gates for function pointers in source defining …
3ed99a2 
…the pointee

We previously defined call gates for pointers to static functions by appending a
macro to the rewritten source files. In that case we had to do this because the
static function may not be referenced from outside the translation unit. For
pointers to globally-visible functions we defined the call gates in the call
gate .so for simplicity. This commit changes the latter call gates so they're
defined like the former. This change simplifies control-flow since the call gate
no longer requires cross-DSO calls and makes it possible to support programs
that are intended to be compiled with -fvisibility=hidden since functions that
may have hidden visibility are only referenced by call gates within the DSO that
defines them. Closes #435.
@ayrtonm ayrtonm mentioned this issue Oct 17, 2024
Merged
ayrtonm added a commit that referenced this issue Oct 17, 2024
@ayrtonm
rewriter: Define call gates for function pointers in source defining …
e82acb9 
…the pointee

We previously defined call gates for pointers to static functions by appending a
macro to the rewritten source files. In that case we had to do this because the
static function may not be referenced from outside the translation unit. For
pointers to globally-visible functions we defined the call gates in the call
gate .so for simplicity. This commit changes the latter call gates so they're
defined like the former. This change simplifies control-flow since the call gate
no longer requires cross-DSO calls and makes it possible to support programs
that are intended to be compiled with -fvisibility=hidden since functions that
may have hidden visibility are only referenced by call gates within the DSO that
defines them. Closes #435.
ayrtonm added a commit that referenced this issue Oct 22, 2024
@ayrtonm
rewriter: Define call gates for function pointers in source defining …
0324836 
…the pointee

We previously defined call gates for pointers to static functions by appending a
macro to the rewritten source files. In that case we had to do this because the
static function may not be referenced from outside the translation unit. For
pointers to globally-visible functions we defined the call gates in the call
gate .so for simplicity. This commit changes the latter call gates so they're
defined like the former. This change simplifies control-flow since the call gate
no longer requires cross-DSO calls and makes it possible to support programs
that are intended to be compiled with -fvisibility=hidden since functions that
may have hidden visibility are only referenced by call gates within the DSO that
defines them. Closes #435.
ayrtonm added a commit that referenced this issue Oct 22, 2024
@ayrtonm
rewriter: Define call gates for function pointers in source defining …
3dcc745 
…the pointee

We previously defined call gates for pointers to static functions by appending a
macro to the rewritten source files. In that case we had to do this because the
static function may not be referenced from outside the translation unit. For
pointers to globally-visible functions we defined the call gates in the call
gate .so for simplicity. This commit changes the latter call gates so they're
defined like the former. This change simplifies control-flow since the call gate
no longer requires cross-DSO calls and makes it possible to support programs
that are intended to be compiled with -fvisibility=hidden since functions that
may have hidden visibility are only referenced by call gates within the DSO that
defines them. Closes #435.
ayrtonm added a commit that referenced this issue Oct 31, 2024
@ayrtonm
rewriter: Move call gates for non-static address-taken functions to s…
2e7801e 
…ource files defining the target

These call gates were originally defined in the call gate .so for simplicity.
Moving them to the source file defining the original address-taken function
simplifies control-flow since it no longer requies cross-DSO calls and makes it
possible to support programs that are intended to be compiled with
-fvisibility=hidden since functions that may have hidden are only referenced by
call gates within the DSO that defines them. Closes #435.
@ayrtonm ayrtonm reopened this Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kkysen kkysen

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ayrtonm @kkysen