Loading plugins with arm-none-eabi-gcc

Andrew Pinski pinskia@gmail.com
Wed Jul 22 08:20:14 GMT 2020


On Wed, Jul 22, 2020 at 12:45 AM Shuai Wang <wangshuai901@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 <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