This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][libomptarget] Build plugins-nextgen/common/PluginInterface with protected visibility
ClosedPublic

Authored by kevinsala on Nov 14 2022, 6:47 PM.

Details

Summary

This commit sets the default visibility of PluginInterface's symbols (in nextgen plugins) as protected. This prevents symbols from a plugin library to be preempted by another plugin library's symbol. It applies the same fix introduced by D136365.

Issue reported by @ggeorgakoudis.

Diff Detail

Event Timeline

kevinsala created this revision.Nov 14 2022, 6:47 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 14 2022, 6:47 PM
kevinsala requested review of this revision.Nov 14 2022, 6:47 PM
jhuber6 accepted this revision.Nov 14 2022, 6:50 PM

LG

openmp/libomptarget/plugins-nextgen/common/PluginInterface/CMakeLists.txt
22–25

nit. I'd prefer it in a single target.

This revision is now accepted and ready to land.Nov 14 2022, 6:50 PM

@jhuber6 Shouldn't we compile the elf_common "library" with protected visibility too?

@jhuber6 Shouldn't we compile the elf_common "library" with protected visibility too?

It should be fine since everything links from a single library. The previous problem was because we had multiple libraries defining the same functions in the plugins.

@jhuber6 Shouldn't we compile the elf_common "library" with protected visibility too?

It should be fine since everything links from a single library. The previous problem was because we had multiple libraries defining the same functions in the plugins.

Double checked, it should be an object library so it doesn't export anything on the library level, then the version script will ensure that we only export the plugin interfaces.

@jhuber6 Shouldn't we compile the elf_common "library" with protected visibility too?

It should be fine since everything links from a single library. The previous problem was because we had multiple libraries defining the same functions in the plugins.

Double checked, it should be an object library so it doesn't export anything on the library level, then the version script will ensure that we only export the plugin interfaces.

Thank you for checking it!

kevinsala updated this revision to Diff 475653.Nov 15 2022, 6:18 PM

Updated to use set_target_properties instead of set_property.

@jhuber6 I'd appreciate if you could commit the patch for me. Thank you in advance.

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Can you check if that symbol is actually protected in the .so you're using?

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Can you check if that symbol is actually protected in the .so you're using?

They are not protected.

➜  readelf -s /home/ac.shilei.tian/Documents/build/openmp/debug/lib/libomptarget.rtl.x86_64.nextgen.so | rg is_va
 77783: 000000000046b7b0   472 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]
 77866: 000000000046b710   157 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Can you check if that symbol is actually protected in the .so you're using?

They are not protected.

➜  readelf -s /home/ac.shilei.tian/Documents/build/openmp/debug/lib/libomptarget.rtl.x86_64.nextgen.so | rg is_va
 77783: 000000000046b7b0   472 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]
 77866: 000000000046b710   157 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]

That's weird, the CMake should have the visibility preset for all of those libraries as far as I can tell. Think you could check the flags it's using to build the library?

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Can you check if that symbol is actually protected in the .so you're using?

They are not protected.

➜  readelf -s /home/ac.shilei.tian/Documents/build/openmp/debug/lib/libomptarget.rtl.x86_64.nextgen.so | rg is_va
 77783: 000000000046b7b0   472 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]
 77866: 000000000046b710   157 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]

That's weird, the CMake should have the visibility preset for all of those libraries as far as I can tell. Think you could check the flags it's using to build the library?

@tianshilei1992 Could you attach the call stack trace too? Thanks!

Currently I'm still encountering the issue that, the function call to __tgt_rtl_is_valid_binary in __tgt_rtl_is_valid_binary_info jumps to another plugin.

Can you check if that symbol is actually protected in the .so you're using?

They are not protected.

➜  readelf -s /home/ac.shilei.tian/Documents/build/openmp/debug/lib/libomptarget.rtl.x86_64.nextgen.so | rg is_va
 77783: 000000000046b7b0   472 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]
 77866: 000000000046b710   157 FUNC    GLOBAL DEFAULT   12 __tgt_rtl_is_val[...]

Shows up protected for me

> readelf -Ws ../../clang/lib/libomptarget.rtl.x86_64.nextgen.so | grep is_valid                                                                                              
   104: 000000000000d850    92 FUNC    GLOBAL PROTECTED   15 __tgt_rtl_is_valid_binary                                                                                                                                 
   113: 00000000000128f0   842 FUNC    GLOBAL PROTECTED   15 __tgt_rtl_is_valid_binary_info