All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] Xtensa toolchain issue ?
Date: Thu, 10 Jan 2019 15:56:49 +0100	[thread overview]
Message-ID: <20190110155649.2e5654cd@windsurf> (raw)
In-Reply-To: <CAMo8BfLe2amCfDH2MdrQH+7PXx16P5BjGy1zMe5gxZ+YkYEtxQ@mail.gmail.com>

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

  reply	other threads:[~2019-01-10 14:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-02 10:21 [Buildroot] Xtensa toolchain issue ? Thomas Petazzoni
2019-01-03 22:17 ` Max Filippov
2019-01-04  9:27   ` Thomas Petazzoni
2019-01-04 23:44     ` Max Filippov
2019-01-10 14:56       ` Thomas Petazzoni [this message]
2019-01-14 20:09         ` Max Filippov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190110155649.2e5654cd@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.