From: Chris E. <cem...@ch...> - 2000-04-28 14:54:35
|
I see that for now umlinux is x86 only at the moment. I'd quite like to see it working on other architectures, particularly powerpc. Has anyone done any work towards it? If so, then I'd like to help. If not, I'd like to have a go at it and would appreciate someone pointing me in the right direction to get started. :-) Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-04-28 16:03:37
|
> If so, then I'd like to help. As far as I know, there are no ongoing porting efforts. > If not, I'd like to have a go at it and > would appreciate someone pointing me in the right direction to get > started. :-) Here are the major items: You need to get uml to compile with the include/asm-um/arch link pointing to ../asm-ppc in your case. Almost all of the asm-um headers just #include their arch equivalents. You'll need to find the exceptions for ppc. Once it compiles, look at all the places that registers are referenced. These are in close proximity to ptrace calls, so grepping for ptrace will show you where they are. Replace those with the ppc equivalents. Run it and watch it work :-) I believe that those two things are it, but since a port has not yet been done, I don't know for sure. If you do start working on this, I need to know what you're running into so I can start thinking about how to abstract the architecture stuff out of the main code. So, keep me updated. My current thinking is that we can put the machine dependent stuff under a generic interface like the upper kernel does now. We'll have arch/i386, arch/ppc, etc somewhere under the arch/um layer. Longer term, this may get ported to other OS's, in which case the host OS would be the visible architecture, and the arch/* that I just described would move under os/linux or something. Jeff |
From: Chris E. <cem...@ch...> - 2000-04-29 15:34:59
|
On Fri, 28 Apr 2000, Jeff Dike wrote: > As far as I know, there are no ongoing porting efforts. Well, there's at least one now... [things which need to be done] > You need to get uml to compile with the include/asm-um/arch > link pointing to ../asm-ppc in your case. Almost all of the asm-um > headers just #include their arch equivalents. You'll need to find > the exceptions for ppc. > Once it compiles, look at all the places that registers are > referenced. These are in close proximity to ptrace calls, so > grepping for ptrace will show you where they are. Replace those > with the ppc equivalents. Well, I've tweaked things far enough to make vmlinux, although the runnable binary doesn't link so far. There are unresolved references to things like atomic_dec, atomic_inc, and local_bh_count. I'll look into those next. > Run it and watch it work :-) Once I get it to link, I'll find out how badly I've broken it. :-) > If you do start working on this, I need to know what you're running > into so I can start thinking about how to abstract the architecture > stuff out of the main code. So, keep me updated. Here are some notes from what I've done so far... General: I had to change the SUBARCH bit in the configuration, and the odd mention of i386 (eg -U__i386__ -> -U__powerpc). The linker script in arch/um also specified the architecture. Registers: There are some places where the code has to be changed quite a lot (eg special handling for segment registers), but a lot of the time it's just things like changing "UESP" to "PT_R1" or whatever it is. I haven't yet decided whether I think having constants like "UM_STACK_REGISTER" or "UM_RETURN_REGISTER", or whether it's better to keep the code entirely separate. The pt_regs structure (the ppc one, not the um one) is quite different (unsurprisingly). I've been using that in a few places instead of an array of length 17, eg the thread_struct. I can get away with this since the PT_foo defines for register offsets are documented as working with the pt_regs structure, but this isn't ideal. I haven't put much thought into it so far. The checksum.S linked to from the arch/ppc/lib didn't compile, since some of the redirected <asm/*.h> includes broke things. For now I've copied the file and included some stuff from <asm-ppc/*.h>. old-checksum.c doesn't exist in PPC, so I removed it from the Makefile. I found a typo in one of the PPC headers (SRGV_ACCERR instead of SEGV_ACCERR). Assuming I didn't manage to insert it accidentally myself, I should submit the patch to the kernel people, I suppose. > My current thinking is that we can put the machine dependent stuff > under a generic interface like the upper kernel does now. We'll > have arch/i386, arch/ppc, etc somewhere under the arch/um layer. I think that makes sense. I'll leave that until I have things working, though... > Longer term, this may get ported to other OS's, in which case the > host OS would be the visible architecture, and the arch/* that I > just described would move under os/linux or something. How far away is that? :-) Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-04-29 17:48:00
|
> Well, there's at least one now... Cool... > Here are some notes from what I've done so far... Can you make your ongoing diffs available somewhere? I'm going to run a parallel effort and do the i386 port. > but a lot of the time it's just things like changing "UESP" to "PT_R1" > or whatever it is. I haven't yet decided whether I think having > constants like "UM_STACK_REGISTER" or "UM_RETURN_REGISTER", or whether > it's better to keep the code entirely separate. If it's just a matter of changing the register number, and the logic is exactly the same, I was planning on introducing things like UM_SP and UM_IP, and have the different arches define them. > The pt_regs structure (the ppc one, not the um one) is quite different > (unsurprisingly). I've been using that in a few places instead of an > array of length 17, eg the thread_struct. The register arrays are going to have to analagous to the thread structure - defined by the underlying arch and included in the thread structure, so the i386 unsigned long[17] will go into the i386 arch and you can define whatever you need for ppc. > The checksum.S linked to from the arch/ppc/lib didn't compile, since > some of the redirected <asm/*.h> includes broke things. For now I've > copied the file and included some stuff from <asm-ppc/*.h>. Things like this will need to be handled by the arch. I guess I can include the arch Makefile and it can add things to $OBJS. BTW, feel free to steal code from arch/ppc. It saves a lot of work :-) > How far away is that? :-) Pretty far, I think :-) Jeff |
From: Chris E. <cem...@ch...> - 2000-05-01 12:41:55
|
I've now got as far as linking the executable under PPC linux, basically by copying bits from arch/ppc until it stopped having unresolved symbols. The first time I ran it it exited from remap_data("rw-") saying "remap_data couldn't find data segment" because there were no entries in /proc/self/maps with those permissions: 10000000-1016a000 rwxp 00000000 03:0d 339044 /home/cme20/working/umlinux/linux/linux 1016a000-1019f000 rwxp 00000000 00:00 0 7ffff000-80000000 rwxp 00000000 00:00 0 Is something actually wrong here, or should it only exit if both remap_data("rwx") and remap_data("rw-") fail? After commenting out the "exit(1)" line it gets as far as saying "POSIX conformance testing by UNIFIX" and then seems to be spinning in the tracing thread. I haven't looked at what it's trying to do yet. I hope to get around to building a patch later today. Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-05-01 13:20:03
|
> The first time I ran it it exited from remap_data("rw-") saying > "remap_data couldn't find data segment" because there were no entries > in /proc/self/maps with those permissions: > 10000000-1016a000 rwxp 00000000 03:0d 339044 /home/cme20/working/umlinux/linux/linux > 1016a000-1019f000 rwxp 00000000 00:00 0 > 7ffff000-80000000 rwxp 00000000 00:00 0 What's going on here is that the kernel is copying its data and bss into two files, unmapping them, and then mapping those files shared in their places. This is to make the kernel data shared across forks. Otherwise, they would end up copy-on-write. remap_data recognizes the appropriate maps by their permissions. It looks like another method is needed for ppc. It looks like there is no separate text and data in the maps. Just text, bss, and stack. Is that right? Why don't we just ditch the permissions comparisons and use _etext and _end. The region between _etext and _end is the data, so just fiddle remap_data to remap that. > Is something actually wrong here, or should it only exit if both > remap_data("rwx") and remap_data("rw-") fail? They both have to succeed. Those permissions are pretty wierd. Does ppc not have the same kind of page protections that x86 does? Jeff |
From: Chris E. <cem...@ch...> - 2000-05-01 14:27:46
|
On Mon, 1 May 2000, Jeff Dike wrote: > What's going on here is that the kernel is copying its data and bss into two > files, unmapping them, and then mapping those files shared in their places. > This is to make the kernel data shared across forks. Otherwise, they would > end up copy-on-write. Ok, that makes sense. > remap_data recognizes the appropriate maps by their permissions. It > looks like another method is needed for ppc. > > It looks like there is no separate text and data in the maps. Just > text, bss, and stack. Is that right? It may be something odd about the linux binary. The maps from /bin/ls look a bit more interesting. One difference is the dynamic linking - linux seems to be static. 0fee8000-0ffc9000 r-xp 00000000 03:09 120950 /lib/libc-2.1.3.so 0ffc9000-0ffd8000 ---p 000e1000 03:09 120950 /lib/libc-2.1.3.so 0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950 /lib/libc-2.1.3.so 0ffeb000-0fff0000 rwxp 00000000 00:00 0 10000000-1000c000 r-xp 00000000 03:09 30304 /bin/ls 1001b000-1001d000 rwxp 0000b000 03:09 30304 /bin/ls 30000000-30014000 r-xp 00000000 03:09 120833 /lib/ld-2.1.3.so 30014000-30015000 rw-p 00000000 00:00 0 30023000-30027000 rwxp 00013000 03:09 120833 /lib/ld-2.1.3.so 7fffe000-80000000 rwxp fffff000 00:00 0 > Why don't we just ditch the permissions comparisons and use _etext > and _end. The region between _etext and _end is the data, so just > fiddle remap_data to remap that. Do you want to do that? :-) > > Is something actually wrong here, or should it only exit if both > > remap_data("rwx") and remap_data("rw-") fail? > They both have to succeed. Ok. Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-05-01 15:13:23
|
> 0fee8000-0ffc9000 r-xp 00000000 03:09 120950 /lib/libc-2.1.3.so > 0ffc9000-0ffd8000 ---p 000e1000 03:09 120950 /lib/libc-2.1.3.so > 0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950 /lib/libc-2.1.3.so These are more like what I'd expect. Except that "---p", that's pretty strange. The ls permissions: > 10000000-1000c000 r-xp 00000000 03:09 30304 /bin/ls > 1001b000-1001d000 rwxp 0000b000 03:09 30304 /bin/ls are still a bit different. It still looks like just text, data, stack, with no separate bss. Where do binaries typically load on ppc? Is ls typical, loading at 0x10000000? If so, we're going to have to move linux higher, like to 0x20000000. > Do you want to do that? :-) I'm in the process of doing that. What I've done so far is get rid of the i386 stuff from the build, and move the ptrace and register stuff into separate directories. So, you'll be able to just do the ppc equivalent of the i386 stuff, and it ought to work. What's the ppc page size? Jeff |
From: Chris E. <cem...@ch...> - 2000-05-01 16:34:18
|
On Mon, 1 May 2000, Jeff Dike wrote: > > 0fee8000-0ffc9000 r-xp 00000000 03:09 120950 /lib/libc-2.1.3.so > > 0ffc9000-0ffd8000 ---p 000e1000 03:09 120950 /lib/libc-2.1.3.so > > 0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950 /lib/libc-2.1.3.so > > These are more like what I'd expect. Except that "---p", that's pretty > strange. Yes, 'tis a bit. The offset 000e1000 puts it in the .data section of the library, I think. > The ls permissions: > > 10000000-1000c000 r-xp 00000000 03:09 30304 /bin/ls > > 1001b000-1001d000 rwxp 0000b000 03:09 30304 /bin/ls > are still a bit different. It still looks like just text, data, stack, with > no separate bss. > Where do binaries typically load on ppc? Is ls typical, loading at > 0x10000000? If so, we're going to have to move linux higher, like > to 0x20000000. That does seem to be typical, although there are a few exceptions (mostly kernel threads). > > Do you want to do that? :-) > > I'm in the process of doing that. Cool. > What I've done so far is get rid of the i386 stuff from the build, > and move the ptrace and register stuff into separate directories. > So, you'll be able to just do the ppc equivalent of the i386 stuff, > and it ought to work. Looking forward to it! > What's the ppc page size? It's 4k, same as i386. Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-05-01 19:59:52
Attachments:
diffs
|
Attached are diffs which abstract away a lot of the arch-dependent stuff: the Makefile calculates SUBARCH other gratuitous mentions of i386 in the Makefile are gone there is now support for Makefile-$(SUBARCH), which for now just specifies an entry point there is support for arch/um/include/sysdep which points to arch/um/include/sysdep-$(SUBARCH), which contains arch-dependent stuff that can be used by both user and kernel code. Currently, this includes just ptrace.h. arch-dependent C code goes in arch/um/sys-$(SUBARCH). This directory is expected to produce a sys.o. mentions of i386 have been removed from the link script ports are expected to define a struct sys_pt_regs in arch/um/include/sysdep/ptrace.h, as well as a bunch of generic macros like UM_SP and UM_SYSCALL_RET currently, ports need to write up 4 procedures, 2 to convert between struct sys_pt_regs and struct sigcontext, and the ptrace putregs and getregs functions remap_data is now portable, I hope I haven't done anything about the files that just get linked to from arch/i386/kernel. Those I'll probably move into arch/um/sys-i386. I think this covers most of the problems that you've told us about so far. Let me know what else you find. The kernel should get past the UNIFIX thing once remap_data works. That's when the kernel tries to start up the init thread. If remap_data didn't work, that doesn't work. You'll need to define the entry point as 0x20000000 to avoid being stomped on by init when you get around to execing it. Jeff |
From: Chris E. <cem...@ch...> - 2000-05-02 02:23:03
Attachments:
umlppc.diff
|
On Mon, 1 May 2000, Jeff Dike wrote: > Attached are diffs which abstract away a lot of the arch-dependent stuff: Good stuff - I've now merged my changes in and have a kernel which goes as far as mounting the root filesystem, although I haven't managed to run an init yet. The patch is attached. It will break i386 in its current state, unfortunately. [snip] > I think this covers most of the problems that you've told us about so far. It does cover most things. > Let me know what else you find. There were a few things... There were some leftover references to Intel registers around. I've added a couple more defines for them. There's one reference to EDX in finish_exec() - what's that one for? My patch changes it to an PPC register, but I don't really know which one it should be. (This is one of the places which will break i386) Although the arch is "ppc", some places need "powerpc", eg the -U__powerpc__ option and link.ld.in. There may need to be an extra level of indirection for that. I covered the former with Makefile-ppc, but for the latter I just edited the link.ld. A few places have actual #ifdef __UM_PPC__ (a define I've added) blocks. Another place should have but doesn't - I've deleted a large chunk of arch/um/kernel/syscall_kern.c for system calls which don't seem to exist on PPC. Oops. I'm not going to fix it now, as it's 3am and I've got work tomorrow, but I'll put the stuff back in with an #ifdef tomorrow if no-one beats me to it. The ppc version of [_]switch_to has a different number of arguments - I've hacked around it with some preprocessor macros in <asm-um/system.h>. I've done something similar for struct sigcontext, which is called struct sigcontext_struct in ppc. There are some references to CR2, which does map to a PPC register (DAR I think) of a different name. I think they could be renamed to something more generic. > The kernel should get past the UNIFIX thing once remap_data works. Correct. :-) > You'll need to define the entry point as 0x20000000 to avoid being > stomped on by init when you get around to execing it. I've done that, although something is still broken. Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2000-05-02 03:44:38
|
> I've now merged my changes in and have a kernel which goes as far as > mounting the root filesystem, although I haven't managed to run an > init yet. The patch is attached. It will break i386 in its current > state, unfortunately. Great. I'm going to go through it and merge in the things that don't break my pool. > There were some leftover references to Intel registers around. I've > added a couple more defines for them. I fixed these. > There's one reference to EDX in finish_exec() - what's that one for? You need to worry about this one. Elf binaries take a value in EDI (on i386) which is an address of an initialization procedure or something. Linux doesn't use it, so it goes in as zero. Look through asm-ppc/*elf*.h for something similar. > I've deleted a large chunk of arch/um/kernel/syscall_kern.c for > system calls which don't seem to exist on PPC. This sucks. > There are some references to CR2, which does map to a PPC register > (DAR I think) of a different name. I think they could be renamed to > something more generic. True. > +#define UM_SP_OFFSET UESP > +#define UM_IP_OFFSET EIP These are wrong, and I bet the ppc equivalents you've got are wrong, too. These are byte offsets so they need to be multiplied by the register length. I.e. #define UM_IP_OFFSET (EIP * sizeof(long)) That might be hurting your attempts to exec init. I would prefer that you have your Makefile make links to arch/ppc files that you're just going to steal whole. That keeps the patch size down, and gives this kernel the benefit of whatever changes are made in those files in the future. On the whole, those changes look fairly clean. Jeff |
From: Chris E. <cem...@ch...> - 2000-05-02 23:38:36
|
On Mon, 1 May 2000, Jeff Dike wrote: [snip] > > There's one reference to EDX in finish_exec() - what's that one > > for? > > You need to worry about this one. Elf binaries take a value in EDI > (on i386) which is an address of an initialization procedure or > something. Linux doesn't use it, so it goes in as zero. Look > through asm-ppc/*elf*.h for something similar. There doesn't seem to be anything similar. There's a comment somewhere saying that i386 takes a pointer to a function to call on exit in EDX, and not mentioning other architectures. Do you know of a good online reference for Elf things like this? > > I've deleted a large chunk of arch/um/kernel/syscall_kern.c for > > system calls which don't seem to exist on PPC. > > This sucks. Indeed. I now have an #ifdef. I think it'd be useful to define a symbol like __UM_$(SUBARCH)__ or something similar for this sort of thing. At least some of the syscalls there will be i386 only, rather than just non-ppc (vm86 springs to mind). > > +#define UM_SP_OFFSET UESP > > +#define UM_IP_OFFSET EIP > > These are wrong, and I bet the ppc equivalents you've got are wrong, > too. Yes, you're absolutely right... brain failure on my part. > I would prefer that you have your Makefile make links to arch/ppc > files that you're just going to steal whole. That keeps the patch > size down, and gives this kernel the benefit of whatever changes are > made in those files in the future. I've done that for bitops.c. The assembler functions are trickier, as they seem to need quite a bit of the environment from arch/ppc. I'll look into it. Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: lars b. <la...@no...> - 2000-04-28 19:30:57
|
Chris Emerson <cem...@ch...> writes: > I see that for now umlinux is x86 only at the moment. I'd quite like > to see it working on other architectures, particularly powerpc. Has > anyone done any work towards it? If so, then I'd like to help. If > not, I'd like to have a go at it and would appreciate someone pointing > me in the right direction to get started. :-) Not that Linux/a386 is anything near as functional as uml is, but it's designed with a very clear separation of the architecture-dependant stuff: Linux/a386 itself written completely in portable C code, and the a386 hardware abstraction library contains C and assembler implementing all architecure-dependant functionality. http://linux.a386.nocrew.org/ http://a386.nocrew.org/ |