public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Andrei Gherzan <andrei@gherzan.com>,
	openembedded <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] gcc: Fix tm.h plugin header
Date: Tue, 21 Dec 2021 12:04:27 +0000	[thread overview]
Message-ID: <fdca8e9d3824e0cf0782cf54d2967c7796b44e28.camel@linuxfoundation.org> (raw)
In-Reply-To: <429927de-21b9-4c9a-8a8f-93a3b64242b1@www.fastmail.com>

On Tue, 2021-12-21 at 11:56 +0000, Andrei Gherzan wrote:
> On Mon, 20 Dec 2021, at 01:39, Bernhard Rosenkränzer via
> lists.openembedded.org wrote:
> > On Thu, Dec 9, 2021 at 07:40 PM, Andrei Gherzan wrote:
> >  
> > > On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
> > >  
> > > > On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan <andrei@gherzan.com>
> > > > wrote:
> > > >  
> > > > > From: Andrei Gherzan <andrei.gherzan@huawei.com>
> > > > > 
> > > > > On x86-64, tm.h (needed to build gcc plugins) tries to include
> > > > > config/i386/linux64.h, which isn't installed. Fortunately it also
> > > > > isn't
> > > > > used, so simply removing the include statement is an ok fix.
> > > > is it due to multilib support ? if so we might be ok since we may not
> > > > be using it
> > > > but really it will be good to check it with multilib builds of
> > > > x86_64/x86
> > > I don't think it is related to multilib but I'll give multilib a try. In
> > > my case, the issue was revealed when compiling a kernel plugin config. I
> > > can't remember right now which one but I can replicate it for logs.
> > Hi,
> > I've had a closer look at the problem, and can confirm the patch doesn't
> > break even in multilib setups.
> > 
> > The problem is that in a non-multilib setup, the config/i386/linux64.h
> > header is not generated, but tm.h tries to include it nevertheless, causing
> > any gcc plugin that #includes tm.h (such as all the gcc plugins in the
> > kernel -- tm.h is included by scripts/gcc-plugins/gcc-common.h) to fail to
> > build.
> > An alternative fix would be adding
> > mkdir -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386
> > touch ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386/lin
> > ux64.h
> > (creating the file if it isn't there) instead. This would make sure that in
> > cases where config/i386/linux64.h does exist, it doesn't get removed from
> > tm.h (potentially fixing plugins that reference any of the #defines in
> > i386/linux64.h without including the file manually -- but I have yet to see
> > any such plugin).
> > 
> > I will try to get a better fix (not adding the include statement to tm.h in
> > the first place rather than having to remove it later in install scripts)
> > upstream, but in the mean time, the patch fixes our builds before the better
> > fix is ready/applied.
> 
> Ping on this patch. Any chance we can pull it in as a first iteration of the
> solution?

I don't like sed in this context as if the code changes, it silently stops
working and we struggle to know what broke or whether we need to fix it. We
don't have any test case.

Given all that, the touch of the file is a neater solution as it is more obvious
what it is doing. I'd also want to see some more detailed comments in the code
about what it is doing and why.

Maintainability of these kinds of fixes is key.

Cheers,

Richard


  reply	other threads:[~2021-12-21 12:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 15:40 [PATCH] gcc: Fix tm.h plugin header Andrei Gherzan
2021-12-09 16:40 ` [OE-core] " Khem Raj
2021-12-09 18:39   ` Andrei Gherzan
2021-12-20  1:39     ` Bernhard Rosenkränzer
2021-12-21 11:56       ` [OE-core] " Andrei Gherzan
2021-12-21 12:04         ` Richard Purdie [this message]
2021-12-23 12:28           ` Andrei Gherzan

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=fdca8e9d3824e0cf0782cf54d2967c7796b44e28.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=andrei@gherzan.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox