From: Greg Ungerer <gregungerer@westnet.com.au>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] status of execve() work - per-architecture patches solicited
Date: Tue, 11 Sep 2012 13:39:54 +1000 [thread overview]
Message-ID: <504EB28A.9080607@westnet.com.au> (raw)
In-Reply-To: <20120910164946.GO13973@ZenIV.linux.org.uk>
On 09/11/2012 02:49 AM, Al Viro wrote:
> On Mon, Sep 10, 2012 at 11:40:11PM +1000, Greg Ungerer wrote:
>> Hi Al,
>>
>> On 09/08/2012 04:20 AM, Al Viro wrote:
>>> To architecture maintainers: please, review the current
>>> situation in git.kernel.org/pub/scm/linux/kernel/git/viro/signal #execve2
>>> and consider sending the corresponding patches for missing architectures.
>>
>> I can see you have some m68k patches in there as well.
>> They tested good on standard m68k (under emulator) and good on non-mmu
>> ColdFire. But it is geting an exception when I run on ColdFire with MMU
>> enabled:
>>
>> ...
>> Creating 1 MTD partitions on "RAM":
>> 0x000000000000-0x0000001b8000 : "ROMfs"
>> TCP: cubic registered
>> NET: Registered protocol family 17
>> VFS: Mounted root (romfs filesystem) readonly on device 31:0.
>> *** FORMAT ERROR *** FORMAT=4
>> Current process id is 1
>> BAD KERNEL TRAP: 00000000
>> Modules linked in:
>> PC: [<0002562a>] 0x02562a
>> SR: 2704 SP: 0383dfc4 a2: 00000000
>> d0: 00000000 d1: 00000000 d2: 00000000 d3: 00000000
>> d4: 00000000 d5: 00000000 a0: 00000000 a1: 00000000
>> Process init (pid: 1, task=0383a000)
>> Frame format=4 eff addr=00000000 pc=6000169a
>> Stack from 0383e000:
>> Call Trace:
>> Code: 6610 4cd7 073e 4fef 0020 201f 588f dfdf <4e73> 2228 0004 46fc
>> 2000 0801 0007 66ff ffff c2ea 598f 4fef ffe8 48d7 78c0 486f
>> Disabling lock debugging due to kernel taint
>>
>> It is trapping at the return from exception (rte) in Lreturn.
>> Looks like it doesn't like the "format" field of the new stack frame
>> for some reason. If I get a few minutes tomorrow I'll dig into it.
>
> Interesting... What it should get is format 0, same as before the change.
Thats a problem on ColdFire. The format field of the stack frame would
normally be 0x4 for a long-word aligned user stack pointer. The current
start_thread code doesn't set this on the ColdFire/MMU case, though we
do for the non-mmu case. The old code inherited this from the stack
frame of exec calling process.
So I will rework the m68k start_thread() code so it sets it explicitly
for all ColdFire cases.
With this fixed up the new exec code works in all cases I have tested
with ColdFire/MMU then.
> BTW, is there any convenient way to get an emulated coldfire-MMU system?
I only test it on real hardware. But it looks like qemu has coldfire
emulation. I haven't tried it, but as of version 1.0 it listed supported
ColdFire CPU's as:
m5206
m5208
cfv4e
The cfv4e core is capable of having an MMU, so maybe someone is working
on it. I must go and check 1.2.0, it might be better.
> For m68k I'm using aranym with sid/m68k from debian-ports.org and it seems
> to work fine these days, but that obviously won't do for coldfire - neither
> the emulator itself, nor the userland (AFAICS, gcc will happily generate
> instructions that use weird addressing modes unless told not to, so I would
> be extremely surprised if normal debian m68k binaries would run on coldfire,
> MMU or no MMU).
Yeah, no way it will work without the appropriate compiler switches on
when generating even userland binaries.
Regards
Greg
> BTW, the same question goes for many other embedded targets - I'm using
> qemu for arm and mips and hercules for s390; alpha, parisc, ppc32 and sparc64 -
> on actual hardware, amd64 and i386 - on kvm guests (all with debian userland);
> ia64 kinda-sorta works with ski, but it's very much imperfect... I think
> sh (at least sh4) should be usable with qemu as well, but I hadn't set that
> up yet. sparc32 is usable on qemu, but only with very old userland.
> Everything else... In theory, quite a few ought to be usable if one
> bootstraps uclinux userland with qemu, but I've no idea how well does that
> work in practice. And seeing that e.g. FRV eval boards go for several
> hundred dollars even on ebay, let alone from manufacturer, I'd rather not
> add the actual hardware to the pile here ;-/
>
> What do people actually use?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-09-11 3:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 18:20 [RFC] status of execve() work - per-architecture patches solicited Al Viro
2012-09-07 18:22 ` Al Viro
2012-09-10 13:40 ` Greg Ungerer
2012-09-10 16:49 ` Al Viro
2012-09-11 3:39 ` Greg Ungerer [this message]
2012-09-13 13:27 ` Greg Ungerer
2012-09-10 22:20 ` Mark Salter
2012-09-10 22:20 ` [PATCH 1/2] c6x: implement ret_from_kernel_execve() and switch to generic kernel_execve() Mark Salter
2012-09-10 22:20 ` [PATCH 2/2] c6x: switch to generic sys_execve() Mark Salter
2012-09-17 3:26 ` [RFC] status of execve() work - per-architecture patches solicited Al Viro
2012-09-21 16:26 ` Mark Salter
2012-09-21 16:26 ` [PATCH 1/3] c6x: add ret_from_kernel_thread(), simplify kernel_thread() Mark Salter
2012-09-21 16:26 ` [PATCH 2/3] c6x: switch to generic kernel_execve Mark Salter
2012-09-21 16:26 ` [PATCH 3/3] c6x: switch to generic sys_execve Mark Salter
2012-09-21 18:39 ` [RFC] status of execve() work - per-architecture patches solicited Al Viro
2012-09-22 11:16 ` Greg Ungerer
2012-09-23 0:46 ` Al Viro
2012-09-24 10:59 ` Vineet Gupta
2012-09-17 9:29 ` Michal Simek
2012-09-17 22:57 ` Al Viro
2012-09-19 12:20 ` Vineet Gupta
2012-09-19 13:32 ` Al Viro
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=504EB28A.9080607@westnet.com.au \
--to=gregungerer@westnet.com.au \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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