Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: Romain Naour <romain.naour@gmail.com>,
	buildroot <buildroot@buildroot.org>,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	"Yann E. MORIN" <yann.morin.1998@free.fr>
Subject: Re: [Buildroot] [PATCH 1/1] package/binutils: disable 2.32 on unuspported FLAT platforms
Date: Tue, 19 Apr 2022 21:42:42 +0200	[thread overview]
Message-ID: <20220419214242.44ee10dd@windsurf> (raw)
In-Reply-To: <CADvTj4rHaz8pVx=mz2Cs4K72D_9ZoF3j6CBp4j=v0xbA5t_H8w@mail.gmail.com>

Hello,

On Sun, 17 Apr 2022 00:50:19 -0600
James Hilliard <james.hilliard1@gmail.com> wrote:

> > I'm not sure that how we want to handle this. Indeed, even with newer
> > binutils versions, I really doubt supporting aarch64 with the FLAT
> > binary format makes a lot of sense.  
> 
> Well our newer binutils versions do already have FLAT disabled
> entirely by setting:
> depends on !BR2_BINFMT_FLAT

Right, but as I state below, this is incorrect: they are disabled
because they introduce a regression on ARM noMMU. Other noMMU
architectures are (as far as we know), not affected.

> > As far as I'm aware, there's currently no practical use-case for Linux
> > noMMU on aarch64 and SH4, so I would simply disallow that. So on ARM, I
> > would only allow the MMU to be disabled on ARMv7-M, and on SuperH, for
> > SH2A. I.e something like the below patch.
> >
> > Of course, that leaves the case of BR2_sh2a. But if binutils
> > 2.35/2.36/2.37 are broken for the FLAT format (which is why they are
> > disabled), and 2.32 is disabled for SH2A/FLAT, then there's nothing
> > left available for SH2A/FLAT  
> 
> Hmm, my assumption was that even though FLAT may not be supported
> by the buildroot toolchain it may be possible some external toolchains
> could have support for them, so I figured best just disable known invalid
> options here for buildroot toolchain binutils.

Practically speaking, nobody is using/testing FLAT on aarch64, SH4 or
other MMU-capable architectures. We should support reasonable use-cases
only IMO.

> > Except that
> > package/binutils/Config.in.host is wrong in disabling 2.35/2.36/2.37
> > for all FLAT configs: the bug is only related to ARM.  
> 
> Hmm, so maybe this set of depends plus an arm exclusion is needed
> for newer binutils?

I'm not following you here.

> > However, I feel strange that sh2a/FLAT was not supported back in
> > binutils 2.32. sh2a/FLAT has been around for a very long time. In fact
> > what happens is that we have a patch to allow sh2a as an architecture
> > name: package/binutils/2.32/0001-sh-conf.patch. But that patch is
> > probably no longer sufficient, and some adjustements are also needed in
> > bfd/config.bfd.  
> 
> So, that patch doesn't seem to add uclinux as a supported target,

No, it makes it support sh2a as an architecture name.

> which seems to be required for BR2_BINFMT_FLAT builds based on:
> https://github.com/buildroot/buildroot/blob/2022.02.1/package/Makefile.in#L44-L45
> https://github.com/buildroot/buildroot/blob/2022.02.1/package/Makefile.in#L40
> https://github.com/buildroot/buildroot/blob/2022.02.1/package/binutils/binutils.mk#L83
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/config.bfd;h=0e1ddb659c3ab7160aab0a7c173b85052f870e65;hb=a9d9a104dde6a749f40ce5c4576a0042a7d52d1f#l1243
> 
> The failures from what I can tell here are due to the lack of a uclinux
> target for sh2a in bfd/config.bfd.

I need to have a closer look it seems.

> > Bottom line: there is more work than just this proposal, which simply
> > papers over the problem without really fixing it.  
> 
> Yeah, that's probably a bit outside my area of expertise, I was just
> adding these dependencies by tracing the configure failure conditions.
> 
> I'm not really familiar with no-mmu builds in general so wouldn't really
> know what's correct for the architecture mmu settings.

Yeah, that's also why I'm advocating for a broader solution. I'll try
to cook some patches. I don't think I'll fix all problems in one go,
but we can progressively get there.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2022-04-19 19:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-09  2:07 [Buildroot] [PATCH 1/1] package/binutils: disable 2.32 on unuspported FLAT platforms James Hilliard
2022-04-13 20:51 ` Thomas Petazzoni via buildroot
2022-04-17  6:50   ` James Hilliard
2022-04-19 19:42     ` Thomas Petazzoni via buildroot [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=20220419214242.44ee10dd@windsurf \
    --to=buildroot@buildroot.org \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=james.hilliard1@gmail.com \
    --cc=romain.naour@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /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