All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nishanth Menon" <nm@ti.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>, <praneeth@ti.com>,
	Denys Dmytriyenko <denis@denix.org>
Subject: Re: [OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make
Date: Mon, 29 Mar 2021 09:08:21 -0500	[thread overview]
Message-ID: <20210329140821.3i7sezuznurbuaqv@smokiness> (raw)
In-Reply-To: <CADkTA4M1+oP3nOnibE+AiLNn3gc9T84dgBzGTqjadW3Hd4+tpA@mail.gmail.com>

On 13:31-20210327, Bruce Ashfield wrote:
> On Thu, Mar 25, 2021 at 9:13 PM Nishanth Menon via
> lists.openembedded.org <nm=ti.com@lists.openembedded.org> wrote:
> >
> > When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
> > the objcopy stage since it seems to be using the local host's objcopy
> > rather than the cross-compile version we want it to use.
> >
> > This can be trivially reproduced in a localbuild of the kernel
> > following the build parameters provided in the process[2]
> >
> > Lets fix this by passing OBJCOPY over to the kernel.
> >
> 
> As I mentioned to Denys, I hadn't seen this. Consulting the
> maintainers file would have found me as a good addition to the cc'.
> 

Sure. understood. Thanks..

> I'm doing some other work on make-mod-scripts dependencies right now,
> so I've pulled this in and will re-test against all of the active
> kernel versions in master.
> 


Thanks.

> But I don't think that make-mod-scripts is the only place we'd need
> this, if it is indeed happening on the tip of all the supported
> versions.  There are routes to have the prepare steps run, without a
> make-mod-scripts dependency.
> 
> We've already made the mistake of letting the make-mod-scrips and
> kernel build parameters diverge (see AR=${KERNEL_AR}), so I need to
> spend a few minutes getting them back in sync.
> 
> I was just able to build and boot qemuarm64 on 5.12-rc4, so there's
> something different about your config than my setup. We need to figure
> that out. It could be a .config triggering different components to be
> built, but unlikely given vdso being involved.
> 
> qemuarm64 login: root
> root@qemuarm64:~# uname -a
> Linux qemuarm64 5.12.0-rc4-yoctodev-standard #1 SMP PREEMPT Mon Mar 22
> 18:46:22 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
> root@qemuarm64:~#

Hmm... only thing I have done is cross compile - see the pastebins.
> 
> > [1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
> > [2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
> > Signed-off-by: Nishanth Menon <nm@ti.com>

[...]
> > diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
> > index 07ec242e63bb..3d25fc7ac531 100644
> > --- a/meta/classes/kernel-arch.bbclass
> > +++ b/meta/classes/kernel-arch.bbclass
> > @@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
> >  HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> >  TARGET_AR_KERNEL_ARCH ?= ""
> >  HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> > +TARGET_OBJCOPY_KERNEL_ARCH ?= ""
> > +HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
> >
> 
> We shouldn't need this TARGET_OBJCOPY_KERNEL_ARCH ->
> HOST_OBJCOPY_KERNEL_ARCH, I can't think of how objcopy would be using
> them.

> 
> Are you setting them to some value in your builds ?

No, I am not. I decided to maintain consistency of usage from LD and AR.
I could'nt think of a usage either, true.


> 
> >  KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd ${DEBUG_PREFIX_MAP} -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
> >  KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
> >  KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
> > +KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}"
> 
> The main kernel Makefile already defines, and the standard env should
> already have both CROSS_COMPILE and OBJCOPY defined to be the target
> version.
> 
> Makefile:OBJCOPY                = $(CROSS_COMPILE)objcopy

OK this is what is confusing me -> I dont see CROSS_COMPILE being set -
which is what I had expected in the first place. other than
meta/recipes-kernel/perf/perf.bb, I dont see it set else where -> I was
really wondering why all the specific usage, when CROSS_COMPILE would
have just done the job.. Then I was guessing maybe the rationale is for
some ancient kernel where CROSS_COMPILE is'nt set right?

> 
> So we really have to pass this, when fundamentally it is the same
> definition as what the defaults give us.
> 
> What does that resolve to in your builds ? In mine, when I dump the
> objcopy value from within the kernel build, I get:
> 
> | /opt/poky/build/tmp/work-shared/qemuarm64/kernel-source/Makefile:443:
> *** objcopy: aarch64-poky-linux-objcopy.  Stop.
> 
> Which should be doing the job.

x86's objcopy - which is why I was trying to figure out what the heck
went on..

> 
> Are you building arm on arm ? or something else like that ?


Nothing fancy.. x86 PC cross compiling for arm. honestly, 5.11 build
went fine. What makes me wonder is how does it even build for you? how
does OBJCOPY variable even point to aarch64-poky-linux-objcopy

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

  reply	other threads:[~2021-03-29 14:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  1:13 [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make Nishanth Menon
2021-03-27  4:25 ` Denys Dmytriyenko
2021-03-27 15:05   ` Bruce Ashfield
2021-03-27 17:31 ` [OE-core] " Bruce Ashfield
2021-03-29 14:08   ` Nishanth Menon [this message]
2021-03-29 15:14     ` Bruce Ashfield
2021-03-29 16:48       ` Nishanth Menon
2021-04-01  0:01       ` Denys Dmytriyenko
2021-04-01 13:16         ` Bruce Ashfield
2021-04-01 15:54           ` Khem Raj
2021-04-01 15:59             ` Bruce Ashfield

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=20210329140821.3i7sezuznurbuaqv@smokiness \
    --to=nm@ti.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=denis@denix.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=praneeth@ti.com \
    /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.