Sorry I am a newbie to cross compilation, but overall, as far as I can see, the following two options both won't work:
1. If I compile instrument_cov.so with gcc as a x86-64bit ELF executable, then it throws the above error (mentioned in my first email) when being loaded by arm-none-eabi-gcc 2. If I compile instrument_cov.so with arm-none-eabi-gcc as a ARM executable, while it looks "consistent" with arm-none-eabi-gcc, but how come it can be correctly loaded and executed on my Ubuntu x86-64 bit? That does not make any sense, right? Am I missing something? Best, Shuai On Wed, Jul 22, 2020 at 7:22 PM Shuai Wang <wangshuai...@gmail.com> wrote: > 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 >> >
