netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: alexei.starovoitov@gmail.com
Cc: netdev@vger.kernel.org
Subject: Re: umh build...
Date: Tue, 05 Jun 2018 19:42:48 -0400 (EDT)	[thread overview]
Message-ID: <20180605.194248.777320854908313205.davem@davemloft.net> (raw)
In-Reply-To: <20180605222932.k4nmh23ggf4pnsft@ast-mbp>

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 5 Jun 2018 15:29:34 -0700

> On Tue, Jun 05, 2018 at 05:03:59PM -0400, David Miller wrote:
>> 
>> Alexei, I tried to build bpfilter on sparc64 and it shows that
>> CONFIG_OUTPUT_FORMAT is an x86 specific Kconfig value.
>> 
>> And, even if I added it, it's not clear what it should even be set to.
>> 
>> Right now, for example, my userland builds default to 32-bit sparc
>> even though I'm building a 64-bit kernel.
>> 
>> I think what ends up happening has to be in some way in response to
>> what kind of "native" binaries HOSTCC is actually building.
> 
> I guess you mean native-ness not of HOSTCC, but what target rootfs will be.

Target rootfs is where I am building the kernel in this case.

Kernel running is 64-bit, most of userland is 32-bit.  Kernel is built
explicitly with "-m64" but gcc by default is building 32-bit.

> I guess it's probably equal to 32 or 64-bitness of the kernel from
> CC.

Nope, they are and can be different, even natively.

> I completely forgot that I need to fix CONFIG_OUTPUT_FORMAT.
> On my arm64 I just did
> export CONFIG_OUTPUT_FORMAT=elf64-littleaarch64
> before doing 'make'.
> I can do a hack to extract it from objdump
> similar to the hack I do for '-B ...'
> Like the patch below...
> and it works on x64 too, but I'm not sure about sparc.
 ...
> @@ -21,7 +21,7 @@ endif
>  # which bpfilter_kern.c passes further into umh blob loader at run-time
>  quiet_cmd_copy_umh = GEN $@
>        cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
> -      $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT) \
> +      $(OBJCOPY) -I binary -O `$(OBJDUMP) -f $<|grep format|cut -d' ' -f8` \
>        -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \
>        --rename-section .data=.init.rodata $< $@

Yeah this doesn't do it in the 64-bit kernel 32-bit userspace scenerio.

We build UMH which ends up being a 32-bit ELF binary, then we later
try to link it:

  ld -m elf64_sparc   -r -o net/bpfilter/bpfilter.o net/bpfilter/bpfilter_kern.o net/bpfilter/bpfilter_umh.o ; scripts/mod/modpost net/bpfilter/bpfilter.o
ld: sparc:v8plusb architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with sparc:v9 output

But your patch is a step in the right direction because it gets us
away from depending upon CONFIG_OUTPUT_FORMAT.

      reply	other threads:[~2018-06-05 23:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 21:03 umh build David Miller
2018-06-05 22:29 ` Alexei Starovoitov
2018-06-05 23:42   ` David Miller [this message]

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=20180605.194248.777320854908313205.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).