Dear Andrew, Thanks a lot. Let me make sure I understand the entire picture here. So basically on my Ubuntu 18.04 x86 machine, I use:
1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc. 2. And also use gcc (version 10.0; x86) to compile the plugin; I tested a number of x86 applications and the plugin works fine. 3. Right now I want to use arm-none-eabi-gcc to load the plugin and do some instrumentation on the GIMPLE code of a program, which is going to be compiled into an ARM binary code. So your point is that this won't work, am I right? You are expecting to: 1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc. 2. And also use arm-none-eabi-gcc to compile the plugin 3. Use arm-none-eabi-gcc to load the plugin and do some instrumentation on the GIMPLE code of a program, which is going to be compiled into an ARM binary code. Am I right? Then my question is, what binary format at step 2 I need to compile the plugin program into? x86, or ARM? Best, Shuai On Wed, Jul 22, 2020 at 4:20 PM Andrew Pinski <pins...@gmail.com> wrote: > On Wed, Jul 22, 2020 at 12:45 AM Shuai Wang <wangshuai...@gmail.com> > wrote: > > > > 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. > > Right because you did not recompile the plugin to use the headers of > arm-none-eabi-gcc compiler. You need to recompile the plugin for that > compiler using the native GCC you compiled the compiler with; that is > you might need to recompile the compiler too. > There is no stable plugin API/ABI here and that is what you are running > into. > > Thanks, > Andrew > > > > > 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 >
