From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 1/2] package: Makefile.in: Add target compilation flags for NOMMU architecture.
Date: Mon, 25 Mar 2013 08:58:31 +0100 [thread overview]
Message-ID: <20130325085831.36ff0afe@skate> (raw)
In-Reply-To: <CAJxxZ0PCJ6X==pGsDajmDoD8mkcimZD58rfwQZyxCFSNTx=Uqg@mail.gmail.com>
Dear Sonic Zhang,
Thanks for following up on this discussion!
On Mon, 25 Mar 2013 15:50:49 +0800, Sonic Zhang wrote:
> > For example, on ARM, you can have ELF or FLAT binaries, that follow
> > either the OABI or EABI. True, OABI is deprecated, but it still clearly
> > points the fact that FLAT is *not* an ABI, but a binary format.
> >
> > Therefore, I think we should introduce config options like:
> >
> > config BR2_BINFMT_ELF
> > bool
> >
> > config BR2_BINFMT_FDPIC
> > bool
> >
> > config BR2_BINFMT_FLAT
> > bool
> >
> > probably with a choice list or something.
> >
>
> OK.
It would be good if this BR2_BINFMT_<foo> thing was introduced as a
separate patch. It can be part of the same patch series, but it would
be could to see it introduced separately from the Blackfin additions.
> >> +ifneq ($(BR2_USE_MMU), y)
> >> +TARGET_CFLAGS += -D__NOMMU__
> >> +endif
> >
> > I'm still not entirely happy with that. This define is completely
> > non-standard, I am not sure we want to have this at the global level.
> > autotools-based packages should be fixed to check if fork() is
> > available or not. For other packages, this special flag can be
> > introduced on a per-package basis. But it's true that maybe a good
> > number of packages will need that. Not sure here. What do others think?
> >
>
> Macro __NOMMU__ is not used only for fork/vfork. There are some
> difference between MMU and NOMMU application. For example:
> - exit(n) should be replaced by _exit(n) in child process.
> - Large buffer or array shouldn't be defined on stack.
> - calloc() should be replaced by malloc().
>
> All these changes to MMU application should be protected by macro __NOMMU__
The issue I have is that this __NOMMU__ define is, as far as I know,
entirely non-standard. So whenever you will send a patch for a package
that introduces some #ifdef __NOMMU__ ... #endif clause, we'll have no
way of pushing it upstream.
Have you managed to pushed upstream noMMU related changes that are
guarded using __NOMMU__ ?
> >> # Configure step. Only define it if not already defined by the package
> >> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> >> index 57b0fd0..5ce32f9 100644
> >> --- a/package/pkg-generic.mk
> >> +++ b/package/pkg-generic.mk
> >> @@ -303,6 +303,11 @@ endif
> >>
> >> $(2)_REDISTRIBUTE ?= YES
> >>
> >> +ifeq ($(BR2_TARGET_ABI_FLAT),y)
> >> + ifneq ($$($(2)_FLAT_STACKSIZE),)
> >> + $(2)_FLAT_LDFLAGS = -Wl,-elf2flt=-s$$($(2)_FLAT_STACKSIZE)
> >> + endif
> >> +endif
> >
> > How is this one supposed to work? Who will use <pkg>_FLAT_LDFLAGS?
>
> If the generic package wants to be built into FLAT binary, it should
> append this package specific link flag <pkg>_FLAT_LDFLAGS to the build
> command line in its makefile. This flag can't be added to
> TARGET_LDFLAGS, because it is package specific.
Hum, right, but then it means that we should modify *all* our packages
so that they add $(<pkg>_FLAT_LDFLAGS) to their LDFLAGS ? Having to
change the recipe of all packages doesn't seem easy to do. Maybe with
enough $ signs we can delay the expansion of TARGET_LDFLAGS so that we
can use a package specific variable in it. Makefile experts? Arnout? :-)
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-03-25 7:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-22 9:01 [Buildroot] [PATCH v3 1/2] package: Makefile.in: Add target compilation flags for NOMMU architecture Sonic Zhang
2013-03-22 9:01 ` [Buildroot] [PATCH v3 2/2] buildroot: target: Add Blackfin architecture support Sonic Zhang
2013-03-22 14:54 ` Thomas Petazzoni
2013-03-25 11:33 ` Sonic Zhang
2013-03-25 11:47 ` Thomas De Schampheleire
2013-03-26 8:16 ` Sonic Zhang
2013-03-26 8:41 ` Thomas Petazzoni
2013-03-26 9:36 ` Sonic Zhang
2013-03-26 10:08 ` Thomas Petazzoni
2013-03-26 7:25 ` Arnout Vandecappelle
2013-03-26 8:15 ` Thomas Petazzoni
2013-03-28 8:20 ` Sonic Zhang
2013-03-28 8:56 ` Thomas Petazzoni
2013-03-29 9:50 ` Sonic Zhang
2013-03-22 14:29 ` [Buildroot] [PATCH v3 1/2] package: Makefile.in: Add target compilation flags for NOMMU architecture Thomas Petazzoni
2013-03-22 17:28 ` Thomas De Schampheleire
2013-03-25 7:11 ` Arnout Vandecappelle
2013-03-25 7:50 ` Sonic Zhang
2013-03-25 7:57 ` Sonic Zhang
2013-03-25 7:58 ` Thomas Petazzoni [this message]
2013-03-25 8:51 ` Sonic Zhang
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=20130325085831.36ff0afe@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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.