public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Loading plugins with arm-none-eabi-gcc
@ 2020-07-22  6:23 Shuai Wang
  2020-07-22  7:20 ` Andrew Pinski
  0 siblings, 1 reply; 6+ messages in thread
From: Shuai Wang @ 2020-07-22  6:23 UTC (permalink / raw)
  To: GCC Development

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!

Best,
Shuai

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Loading plugins with arm-none-eabi-gcc
  2020-07-22  6:23 Loading plugins with arm-none-eabi-gcc Shuai Wang
@ 2020-07-22  7:20 ` Andrew Pinski
  2020-07-22  7:45   ` Shuai Wang
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Pinski @ 2020-07-22  7:20 UTC (permalink / raw)
  To: Shuai Wang; +Cc: GCC Development

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Loading plugins with arm-none-eabi-gcc
  2020-07-22  7:20 ` Andrew Pinski
@ 2020-07-22  7:45   ` Shuai Wang
  2020-07-22  8:20     ` Andrew Pinski
  0 siblings, 1 reply; 6+ messages in thread
From: Shuai Wang @ 2020-07-22  7:45 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: GCC Development

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
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Loading plugins with arm-none-eabi-gcc
  2020-07-22  7:45   ` Shuai Wang
@ 2020-07-22  8:20     ` Andrew Pinski
  2020-07-22 11:22       ` Shuai Wang
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Pinski @ 2020-07-22  8:20 UTC (permalink / raw)
  To: Shuai Wang; +Cc: GCC Development

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Loading plugins with arm-none-eabi-gcc
  2020-07-22  8:20     ` Andrew Pinski
@ 2020-07-22 11:22       ` Shuai Wang
  2020-07-24  3:05         ` Shuai Wang
  0 siblings, 1 reply; 6+ messages in thread
From: Shuai Wang @ 2020-07-22 11:22 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: GCC Development

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 <pinskia@gmail.com> wrote:

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Loading plugins with arm-none-eabi-gcc
  2020-07-22 11:22       ` Shuai Wang
@ 2020-07-24  3:05         ` Shuai Wang
  0 siblings, 0 replies; 6+ messages in thread
From: Shuai Wang @ 2020-07-24  3:05 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: GCC Development

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 <wangshuai901@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 <pinskia@gmail.com> wrote:
>
>> 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
>>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-07-24  3:05 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-22  6:23 Loading plugins with arm-none-eabi-gcc Shuai Wang
2020-07-22  7:20 ` Andrew Pinski
2020-07-22  7:45   ` Shuai Wang
2020-07-22  8:20     ` Andrew Pinski
2020-07-22 11:22       ` Shuai Wang
2020-07-24  3:05         ` Shuai Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).