Loading plugins with arm-none-eabi-gcc

Shuai Wang wangshuai901@gmail.com
Wed Jul 22 07:45:21 GMT 2020


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 <pinskia@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
>


More information about the Gcc mailing list