[Buildroot] Xtensa toolchain issue ?

[Buildroot] Xtensa toolchain issue ?

[Thomas Petazzoni]

Hello Max,

We have a build failure of the libtorrent-rasterbar package that seems
to be toolchain related, and happens on Xtensa:

  http://autobuild.buildroot.net/?reason=libtorrent-rasterbar-1.1.11

The failure looks like this:

In file included from peer_connection.cpp:56:0:
../include/libtorrent/peer_connection.hpp:550:8: error: generic thunk code fails for method 'virtual void libtorrent::peer_connection::_ZThn96_NK10libtorrent15peer_connection8peer_logENS_14peer_log_alert11direction_tEPKcS4_z(libtorrent::peer_log_alert::direction_t, const char*, const char*, ...) const' which uses '...'
   void peer_log(peer_log_alert::direction_t direction
        ^~~~~~~~
  CXX      packet_buffer.lo

It is worth mentioning though that the exact same issue happens on the
OpenRISC architecture, and that Xtensa and OpenRISC seem to be the two
only affected architectures.

It is apparently a bug in gcc 7.x, that has been fixed in gcc 8.x,
according to https://bugzilla.redhat.com/show_bug.cgi?id=1511021, but
this bug report doesn't give any detail on which commit could have
fixed that.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Xtensa toolchain issue ?

[Max Filippov]

Hi Thomas,

On Wed, Jan 2, 2019 at 2:21 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> We have a build failure of the libtorrent-rasterbar package that seems
> to be toolchain related, and happens on Xtensa:
>
>   http://autobuild.buildroot.net/?reason=libtorrent-rasterbar-1.1.11
>
> The failure looks like this:
>
> In file included from peer_connection.cpp:56:0:
> ../include/libtorrent/peer_connection.hpp:550:8: error: generic thunk code fails for method 'virtual void libtorrent::peer_connection::_ZThn96_NK10libtorrent15peer_connection8peer_logENS_14peer_log_alert11direction_tEPKcS4_z(libtorrent::peer_log_alert::direction_t, const char*, const char*, ...) const' which uses '...'
> It is apparently a bug in gcc 7.x, that has been fixed in gcc 8.x,
> according to https://bugzilla.redhat.com/show_bug.cgi?id=1511021, but
> this bug report doesn't give any detail on which commit could have
> fixed that.

My understanding is that this is not something that could be fixed
in a generic way, but requires support from the compiler backend.
Specifically it needs a way to tail-call a variadic function from a
thunk, something that is not trivial to do on xtensa architecture.
The corresponding test in the gcc test suite
(gcc/testsuite/g++.old-deja/g++.jason/thunk3.C)
has been disabled since 2002.

The test in the bug that you've referenced still fails on xtensa with
gcc 8 and gcc 9.

I'll try to implement required support in the xtensa backend for the
above to work.
--
Thanks.
-- Max

[Buildroot] Xtensa toolchain issue ?

[Thomas Petazzoni]

Hello Max,

As usual, thanks a lot for your feedback, very useful.

On Thu, 3 Jan 2019 14:17:51 -0800, Max Filippov wrote:

> My understanding is that this is not something that could be fixed
> in a generic way, but requires support from the compiler backend.
> Specifically it needs a way to tail-call a variadic function from a
> thunk,

This is intricate compiler stuff. If you have a bit of time to give a
few more details about this, I'd be interested. Of course, that's just
to satisfy my endless curiosity, so if you don't have time/interest,
you can skip this request :-)

> something that is not trivial to do on xtensa architecture.
> The corresponding test in the gcc test suite
> (gcc/testsuite/g++.old-deja/g++.jason/thunk3.C)
> has been disabled since 2002.
> 
> The test in the bug that you've referenced still fails on xtensa with
> gcc 8 and gcc 9.
> 
> I'll try to implement required support in the xtensa backend for the
> above to work.

Since the issue also happens on OpenRISC, perhaps we need to have some
BR2_TOOLCHAIN_SUPPORTS_XYZ boolean that says whether the gcc version
supports this specific stuff. However, since I don't clearly understand
what the issue is, I wouldn't be able to find a good name for that
BR2_TOOLCHAIN_SUPPORTS_XYZ option.

BR2_TOOLCHAIN_SUPPORTS_TAIL_CALL_VARIADIC_FUNC_FROM_THUNK ? :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Xtensa toolchain issue ?

[Max Filippov]

On Fri, Jan 4, 2019 at 1:27 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> On Thu, 3 Jan 2019 14:17:51 -0800, Max Filippov wrote:
> > My understanding is that this is not something that could be fixed
> > in a generic way, but requires support from the compiler backend.
> > Specifically it needs a way to tail-call a variadic function from a
> > thunk,
>
> This is intricate compiler stuff. If you have a bit of time to give a
> few more details about this, I'd be interested. Of course, that's just
> to satisfy my endless curiosity, so if you don't have time/interest,
> you can skip this request :-)

A thunk function is used to implement C++ virtual function calls with
multiple inheritance. Probably the best explanation is a quote from
the gccint:

     These functions represent stub code that adjusts the 'this' pointer
     and then jumps to another function.  When the jumped-to function
     returns, control is transferred directly to the caller, without
     returning to the thunk.  The first parameter to the thunk is always
     the 'this' pointer; the thunk should add 'THUNK_DELTA' to this
     value.  (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.)

     Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the
     adjusted 'this' pointer must be adjusted again.  The complete
     calculation is given by the following pseudo-code:

          this += THUNK_DELTA
          if (THUNK_VCALL_OFFSET)
            this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]

     Finally, the thunk should jump to the location given by
     'DECL_INITIAL'; this will always be an expression for the address
     of a function.

and then later, in the description of macro
TARGET_ASM_OUTPUT_MI_THUNK:

     If you do not define this macro, the target-independent code in the
     C++ front end will generate a less efficient heavyweight thunk that
     calls FUNCTION instead of jumping to it.  The generic approach does
     not support varargs.

> Since the issue also happens on OpenRISC, perhaps we need to have some
> BR2_TOOLCHAIN_SUPPORTS_XYZ boolean that says whether the gcc version
> supports this specific stuff. However, since I don't clearly understand
> what the issue is, I wouldn't be able to find a good name for that
> BR2_TOOLCHAIN_SUPPORTS_XYZ option.
>
> BR2_TOOLCHAIN_SUPPORTS_TAIL_CALL_VARIADIC_FUNC_FROM_THUNK ? :-)

Maybe BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK?

-- 
Thanks.
-- Max

[Buildroot] Xtensa toolchain issue ?

[Thomas Petazzoni]

Hello Max,

On Fri, 4 Jan 2019 15:44:36 -0800, Max Filippov wrote:

> A thunk function is used to implement C++ virtual function calls with
> multiple inheritance. Probably the best explanation is a quote from
> the gccint:
> 
>      These functions represent stub code that adjusts the 'this' pointer
>      and then jumps to another function.  When the jumped-to function
>      returns, control is transferred directly to the caller, without
>      returning to the thunk.  The first parameter to the thunk is always
>      the 'this' pointer; the thunk should add 'THUNK_DELTA' to this
>      value.  (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.)
> 
>      Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the
>      adjusted 'this' pointer must be adjusted again.  The complete
>      calculation is given by the following pseudo-code:
> 
>           this += THUNK_DELTA
>           if (THUNK_VCALL_OFFSET)
>             this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
> 
>      Finally, the thunk should jump to the location given by
>      'DECL_INITIAL'; this will always be an expression for the address
>      of a function.
> 
> and then later, in the description of macro
> TARGET_ASM_OUTPUT_MI_THUNK:
> 
>      If you do not define this macro, the target-independent code in the
>      C++ front end will generate a less efficient heavyweight thunk that
>      calls FUNCTION instead of jumping to it.  The generic approach does
>      not support varargs.

Thanks for the additional explanation, very useful!

> > Since the issue also happens on OpenRISC, perhaps we need to have some
> > BR2_TOOLCHAIN_SUPPORTS_XYZ boolean that says whether the gcc version
> > supports this specific stuff. However, since I don't clearly understand
> > what the issue is, I wouldn't be able to find a good name for that
> > BR2_TOOLCHAIN_SUPPORTS_XYZ option.
> >
> > BR2_TOOLCHAIN_SUPPORTS_TAIL_CALL_VARIADIC_FUNC_FROM_THUNK ? :-)  
> 
> Maybe BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK?

Sounds like a good name. Do you want to cook a patch for this, or
should I do so ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Xtensa toolchain issue ?

[Max Filippov]

On Thu, Jan 10, 2019 at 6:57 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> > > Since the issue also happens on OpenRISC, perhaps we need to have some
> > > BR2_TOOLCHAIN_SUPPORTS_XYZ boolean that says whether the gcc version
> > > supports this specific stuff. However, since I don't clearly understand
> > > what the issue is, I wouldn't be able to find a good name for that
> > > BR2_TOOLCHAIN_SUPPORTS_XYZ option.
> > >
> > > BR2_TOOLCHAIN_SUPPORTS_TAIL_CALL_VARIADIC_FUNC_FROM_THUNK ? :-)
> >
> > Maybe BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK?
>
> Sounds like a good name. Do you want to cook a patch for this, or
> should I do so ?

Let me try to come up with a patch.

-- 
Thanks.
-- Max