All of 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 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.