Re: binutils arm-none and arm-linux
[Moving to debian-cross list]
+++ Thomas Preud'homme [2014-12-01 14:35 -0000]:
> > From: Wookey [mailto:wookey@wookware.org]
> > Sent: Monday, December 01, 2014 2:22 PM
> >
> > It occurs to me - do we actually need separate packages/builds of binutils
> > for arm-none and arm-linux?
>
> Good question.
>
> >
> > Binutils doesn't depend on target-arch libs the way that gcc does, so
> > what is the actual difference between binutils-arm-none-gnueabi and
> > binutils-arm-linux-gnueabi?
> >
> > Should/could we make one package that builds both? I guess the actual
> > difference is not the ABI but the defaults set for targetting M0/M3/M4
> > vs A-class v4t/v7. I don't know enough about this to know if
> > maintaining two packages is the best way to do this or not.
>
> There is an important difference is that both have different upstream. AIUI,
> the Linux one as the Linaro toolchain as upstream while the bare-metal one
> is a packaging of the toolchain released by ARM.
None of binutils-arm-none-eabi, cross-binutils (the two wrappers), nor
even binutils-source itself contain any patches. So so far as I can tell we
are already building both cross- packages from a common base.
The linux one is used for all arches, not just arm, but I'm not
sure to what degree it's upstream binutils or linaro-modified
binutils. The control file says it's from:
https://code.launchpad.net/~doko/binutils/pkg-2.25-debian
My understanding is that it is GNU binutils with a selection of
patches (now commits) for debian fixes or from Linaro and possibly
other places, including your changes for the arm-none support. It says
'Snapshot, taken from the 2.25 branch' I'm not sure if that is GNU
upstream branch or something else? Doko?
> In practice different patches are applied, like the patch to support recently
> released Cortex-M7 processors.
Well. I thought that too, but I can't actually see any evidence of
that. It looks to me like they are all already been integrated.
Although binutils-source _does_ have patches in. I'm not sure where
they are coming from. None of them are obviously arm-none related, but
I've not looked in detail.
> As to the default ABI I don't know if gas has a default mode to be honest.
> If not, I guess the applying the patch from this binutils to the linux one
> would be alright but would probably make the merging of changes of the
> embedded toolchain more difficult to apply on Debian's ARM cross binutils
> package. But I agree that the savings might make it worthwhile.
>
> >
> > Just a thought. But if one cross-binutils package can do everything
> > then we should probably just make it spit out the various falvours we
> > need?
>
> You mean like one source package and several binary packages? That would
> be a nice way to get around the default ABI problem if there is such a problem
> indeed.
Right. The arm-none binaries are constructed with a pile of configure
options to turn stuff off and set up the right set of multilibs, so
there presumably is a fair divergence from the linux defaults, but one
would have to check what the default set is. The rules files are
currently quite divergent so it would take a bit of work to merge.
> I'll take a look at this but I guess we are talking Jessie+1 (I forgot its
> name), right?
Definitely. ('Stretch'). No hurry here, I just noticed the duplication
of source packages and wondered if it was necessary.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: