These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch makes it possible to suppress AOUT support in the ELF binfmt.
MN10300 does not support the AOUT binfmt, so the ELF binfmt should not be
permitted to go looking for AOUT libraries to load.
The second patch adds the architecture itself, to be selected by ARCH=mn10300
on the make command line.
The patches can also be downloaded from:
http://people.redhat.com/~dhowells/mn10300/mn10300-arch.tar.bz2
A suitable toolchain can be downloaded from:
ftp://ftp.redhat.com/pub/redhat/gnupro/AM33/
The latest is currently:
am33-04r2-5/tools/i686-pc-linux-gnulibc2.3-x-am33_2.0-linux-gnu.tar.bz2
David
Suppress AOUT library support in ELF binfmt if CONFIG_BINFMT_AOUT is not set.
The MN10300 architecture does not support the AOUT binfmt, so the ELF binfmt
should not be permitted to go looking for AOUT libraries to load.
Signed-off-by: David Howells <[email protected]>
---
fs/binfmt_elf.c | 30 ++++++++++++++++++++++--------
include/linux/a.out.h | 6 ++++++
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index ba8de7c..b734848 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -464,6 +464,7 @@ out:
return error;
}
+#ifdef CONFIG_BINFMT_AOUT
static unsigned long load_aout_interp(struct exec *interp_ex,
struct file *interpreter)
{
@@ -509,6 +510,10 @@ static unsigned long load_aout_interp(struct exec *interp_ex,
out:
return elf_entry;
}
+#else
+extern unsigned long load_aout_interp(struct exec *interp_ex,
+ struct file *interpreter);
+#endif
/*
* These are the functions used to load ELF style executables and shared
@@ -516,9 +521,15 @@ out:
*/
#define INTERPRETER_NONE 0
-#define INTERPRETER_AOUT 1
#define INTERPRETER_ELF 2
+#ifdef CONFIG_BINFMT_AOUT
+#define INTERPRETER_AOUT 1
+#define IS_AOUT_INTERP(x) ((x) == INTERPRETER_AOUT)
+#else
+#define IS_AOUT_INTERP(x) (0)
+#endif
+
#ifndef STACK_RND_MASK
#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
#endif
@@ -734,6 +745,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
/* Some simple consistency checks for the interpreter */
if (elf_interpreter) {
static int warn;
+#ifdef CONFIG_BINFMT_AOUT
interpreter_type = INTERPRETER_ELF | INTERPRETER_AOUT;
/* Now figure out which format our binary is */
@@ -741,11 +753,13 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
(N_MAGIC(loc->interp_ex) != ZMAGIC) &&
(N_MAGIC(loc->interp_ex) != QMAGIC))
interpreter_type = INTERPRETER_ELF;
-
+#else
+ interpreter_type = INTERPRETER_ELF;
+#endif
if (memcmp(loc->interp_elf_ex.e_ident, ELFMAG, SELFMAG) != 0)
interpreter_type &= ~INTERPRETER_ELF;
- if (interpreter_type == INTERPRETER_AOUT && warn < 10) {
+ if (IS_AOUT_INTERP(interpreter_type) && warn < 10) {
printk(KERN_WARNING "a.out ELF interpreter %s is "
"deprecated and will not be supported "
"after Linux 2.6.25\n", elf_interpreter);
@@ -774,7 +788,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
/* OK, we are done with that, now set up the arg stuff,
and then start this sucker up */
- if ((!bprm->sh_bang) && (interpreter_type == INTERPRETER_AOUT)) {
+ if (IS_AOUT_INTERP(interpreter_type) && !bprm->sh_bang) {
char *passed_p = passed_fileno;
sprintf(passed_fileno, "%d", elf_exec_fileno);
@@ -961,7 +975,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
}
if (elf_interpreter) {
- if (interpreter_type == INTERPRETER_AOUT)
+ if (IS_AOUT_INTERP(interpreter_type))
elf_entry = load_aout_interp(&loc->interp_ex,
interpreter);
else
@@ -990,7 +1004,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
kfree(elf_phdata);
- if (interpreter_type != INTERPRETER_AOUT)
+ if (!IS_AOUT_INTERP(interpreter_type))
sys_close(elf_exec_fileno);
set_binfmt(&elf_format);
@@ -1006,14 +1020,14 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
compute_creds(bprm);
current->flags &= ~PF_FORKNOEXEC;
retval = create_elf_tables(bprm, &loc->elf_ex,
- (interpreter_type == INTERPRETER_AOUT),
+ IS_AOUT_INTERP(interpreter_type),
load_addr, interp_load_addr);
if (retval < 0) {
send_sig(SIGKILL, current, 0);
goto out;
}
/* N.B. passed_fileno might not be initialized? */
- if (interpreter_type == INTERPRETER_AOUT)
+ if (IS_AOUT_INTERP(interpreter_type))
current->mm->arg_start += strlen(passed_fileno) + 1;
current->mm->end_code = end_code;
current->mm->start_code = start_code;
diff --git a/include/linux/a.out.h b/include/linux/a.out.h
index f913cc3..7a890e8 100644
--- a/include/linux/a.out.h
+++ b/include/linux/a.out.h
@@ -1,6 +1,8 @@
#ifndef __A_OUT_GNU_H__
#define __A_OUT_GNU_H__
+#ifdef CONFIG_BINFMT_AOUT
+
#define __GNU_EXEC_MACROS__
#ifndef __STRUCT_EXEC_OVERRIDE__
@@ -265,4 +267,8 @@ struct relocation_info
#endif /* no N_RELOCATION_INFO_DECLARED. */
+#else /* CONFIG_BINFMT_AOUT */
+struct exec {
+};
+#endif /* CONFIG_BINFMT_AOUT */
#endif /* __A_OUT_GNU_H__ */
On 10/29/07, David Howells <[email protected]> wrote:
> The second patch adds the architecture itself, to be selected by ARCH=mn10300
> on the make command line.
Why don't you use `am33' for the arch name?
Do you have any plans to support am30 (mn10300) or any pre-am33 processor cores?
I know the mn10300-* target configurations are also available for toolchains,
but it is for historical reasons.
Even the GNUPro packages have the release name am33-04r2-5 instead of mn10300-*.
The same arch name would be better for the same architecture
among the toolchains, the kernel and the library, not to confuse contributors.
GNU libc has used am33 for the machine name since the architecture was
supported.
--
Suzuki Takashi
Japan
Suzuki Takashi <[email protected]> wrote:
> Why don't you use `am33' for the arch name?
History and the fact that 'mn10300' is what MEI called their arch when they
originally gave us (RH) their kernel. There are kernels already out there
running on consumer devices for which it is the mn10300 arch.
David
On 10/30/07, David Howells <[email protected]> wrote:
> > Why don't you use `am33' for the arch name?
>
> History and the fact that 'mn10300' is what MEI called their arch when they
> originally gave us (RH) their kernel. There are kernels already out there
> running on consumer devices for which it is the mn10300 arch.
I see.
But the arch name change does not affect running kernels on consumer devices.
And it wouldn't have so much impact on developers.
Drastic changes in the directory and file structures will have
a much greater impact than that.
This submission is a good chance for the new arch name.
New contributors cannot recognize the am33 glibc is for the mn10300 Linux.
--
Suzuki Takashi
Japan
Suzuki Takashi <[email protected]> wrote:
> But the arch name change does not affect running kernels on consumer devices.
uname says mn10300.
> Drastic changes in the directory and file structures will have
> a much greater impact than that.
Like renaming the arch/mn10300 and include/asm-mn10300 directories and having
to tell people already using ARCH=mn10300 that they've got to change.
> This submission is a good chance for the new arch name.
It's also a good time to leave it as is, IMO. This isn't precisely a new
arch. It's been around a few years. It just hasn't been posted upstream till
now. People are using it, however.
> New contributors cannot recognize the am33 glibc is for the mn10300 Linux.
They can if they're told so, plus if they've got the CPU docs to hand, it
should be more obvious. The AM33 is a variant of the MN10300 arch as far as I
can tell.
David
> They can if they're told so, plus if they've got the CPU docs to
> hand, it should be more obvious. The AM33 is a variant of the
> MN10300 arch as far as I can tell.
Right, there's also the AM30, AM31, AM32, and AM34. Panasonic calls
the whole series the "AM3" or "MN103 series" although they also have
MN103E and MN103S series. MN103E is the AM33/AM34 microprocessors
(MMU), MN103S is the AM3[012] microcontrollers (no MMU).
http://www.semicon.panasonic.co.jp/e-micom/MicomFamily/roadmap.html
On 10/31/07, David Howells <[email protected]> wrote:
> > But the arch name change does not affect running kernels on consumer devices.
>
> uname says mn10300.
Oh, I forgot.
But is there any utility that depends on that uname says mn10300?
> > Drastic changes in the directory and file structures will have
> > a much greater impact than that.
>
> Like renaming the arch/mn10300 and include/asm-mn10300 directories and having
> to tell people already using ARCH=mn10300 that they've got to change.
I know existing developers should learn the arch name change.
But how many developers?
> > New contributors cannot recognize the am33 glibc is for the mn10300 Linux.
>
> They can if they're told so, plus if they've got the CPU docs to hand, it
> should be more obvious. The AM33 is a variant of the MN10300 arch as far as I
> can tell.
That's the point. They must always be told or consult the documentations.
Don't you think an arch name should be natural?
People need not to be told on other, at least major, archs.
It's
- growing new developers will have difficulties in understanding arch
name difference,
versus
- fewer people have to learn the arch name change.
I vote the latter now.
--
Suzuki Takashi
Japan
Suzuki Takashi <[email protected]> wrote:
> But is there any utility that depends on that uname says mn10300?
autoconf:-)
> I know existing developers should learn the arch name change.
> But how many developers?
I don't know. MEI probably does.
> That's the point. They must always be told or consult the documentations.
> Don't you think an arch name should be natural?
Can you guarantee there won't be any non-AM33 variants of mn10300 that need
supporting? An AM34, perhaps?
So basically, the toolchain name should change from am33 to mn10300 by your
argument.
> People need not to be told on other, at least major, archs.
There are plenty of other complications for other archs, such as 32-bit vs
64-bit, LE vs BE and other more subtle variants, so your argument isn't that
compelling.
> - growing new developers will have difficulties in understanding arch
> name difference,
You tell them, they then know. It doesn't take long. Standard practice, I
suspect, will involve giving them the toolchains and basic root filesystems.
The discrepancy has been around for years, and I suspect it's not going to
change now. If MEI ask, I will change it.
David
> Can you guarantee there won't be any non-AM33 variants of mn10300 that need
> supporting? An AM34, perhaps?
>
> So basically, the toolchain name should change from am33 to mn10300 by your
> argument.
Given the "i686" toolchain name is wrong (its actually i686 + cmov) there
is a ton of history for the tool chain name not matching up and its even
happened on PC - and there are tools like rpm that have to know about the
mismatches and already cope.
Sorry for the late.
On 10/31/07, David Howells <[email protected]> wrote:
> > But is there any utility that depends on that uname says mn10300?
>
> autoconf:-)
I forgot again the one as an host environment. :-)
AFAIK, mn10300 series are for embedded systems and I've never heard as
development hosts.
I had noticed the new machine name needs to be added / changed, though.
> Can you guarantee there won't be any non-AM33 variants of mn10300 that need
> supporting? An AM34, perhaps?
I think `am33' is a reasonable name if it is the first variant of
mn10300 series
that is supported by Linux, like `am33' is for glibc and `i386' is
(was) for Linux and others.
People don't misunderstand that an AM30, AM31 or AM32 is supported by Linux.
AM3n seems to be upper compatible with AM3(n-1), so far.
MEI (and only they) know if AM34, and any newer core in that series
are compatible with AM33.
> The discrepancy has been around for years, and I suspect it's not going to
> change now. If MEI ask, I will change it.
I see.
I know there is no technical problem if the arch name continues to be mn10300.
It is an issue of some branding strategy, or a designing policy.
I understand you (RH) are not in a position to decide to change, nor
to refuse to change.
I just noticed and became worried about the mismatch.
If MEI ask you to change the toolchain name from am33 to mn10300, I
have no objection to that.
I'd be glad to hear any comments from MEI.
--
Suzuki Takashi
Japan