Hey Andrew, Thanks a lot for getting back to me. No I am not. Let me clarify the context here:
1. On my Ubuntu (x86-64 version), I use x86 gcc (version 10.0) to compile this plugin, and test this plugin on various programs' GIMPLE code during its compilation with x86 gcc (version 10.0). 2. Then, I switched to use arm-none-eabi-gcc to load this plugin, and encountered the above issue. 3. Since I am doing a cross-platform compilation (on Ubuntu x86), I am anticipating to NOT directly compile my plugin (as a typical .so shared library) into an ARM library, right? Otherwise it cannot be loaded and executed on x86 Ubuntu, right? 4. Then it seems to me that still, the proper way is to compile a x86 plugin, and then somewhat use the arm-none-eabi-gcc to load the plugin during cross architecture compilation? Best, Shuai On Wed, Jul 22, 2020 at 3:20 PM Andrew Pinski <pins...@gmail.com> wrote: > On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc <gcc@gcc.gnu.org> > wrote: > > > > Hello, > > > > I am currently trying to migrate a gcc plugin that has been well > developed > > for x86 code to ARM platform (for arm-none-eabi-gcc). > > > > Currently I did the following steps: > > > > 1. write a hello world program t.c > > > > 2. compile with the following commands: > > > > ➜ arm-none-eabi-gcc -v > > ...... > > gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain > > 9-2020-q2-update) > > > > ➜ arm-none-eabi-gcc -S -mcpu=cortex-m3 -mthumb -fdump-tree-all t.c > > > > It works fine, and can smoothly print out all gimple code at different > > stages. > > > > 3. Load my plugin (the plugin is compiled by x64 gcc version 10.0): > > > > ➜ file instrument_san_cov.so > > instrument_san_cov.so: ELF 64-bit LSB shared object, x86-64, version 1 > > (SYSV), dynamically linked, with debug_info, not stripped > > ➜ file arm-none-eabi-gcc > > arm-none-eabi-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for > GNU/Linux > > 2.6.24, BuildID[sha1]=fbadd6adc8607f595caeccae919f3bab9df2d7a6, stripped > > > > ➜ arm-none-eabi-gcc -fplugin=./instrument_cov.so -S -mcpu=cortex-m3 > > -mthumb -fdump-tree-all t.c > > cc1: error: cannot load plugin ./instrument_cov.so > > ./instrument_cov.so: undefined symbol: > > _Z20build_string_literaliPKcP9tree_nodem > > > > ➜ c++filt -n _Z20build_string_literaliPKcP9tree_nodem > > build_string_literal(int, char const*, tree_node*, unsigned long) > > > > > > It seems that somewhat a function named `build_string_literal` cannot be > > found. Why is that? I have no idea how to proceed on this matter and > cannot > > find some proper documents. Any suggestion would be appreciated. Thank > you! > > Did you compile your plugin with the headers from the GCC that you are > using to load the plugin into? > If not, then it won't work. Note build_string_literal changed between > GCC 9 and GCC 10 in the source and GCC plugin ABI is not stable > between releases at all. > > Thanks, > Andrew > > > > > Best, > > Shuai >
