From: Cameron P. <ca...@pa...> - 2003-12-20 05:20:38
|
Hi all, I've been looking into porting User-Mode Linux to the alpha. I've made a start by copying the i386-specific bits into {sys,sysdep,etc}-alpha, following the porting guide on u-m-l.sf.net (which is sadly out of date), and generally hacking stuff so that it looked appropriate. Large portions of the kernel now seem to compile :-D. Anyway, now I come to this mailing list in search of some explanations for How UML Works these days in those places where that web site bears little correlation with reality and I've been unable to work things out for myself. - I'm having trouble getting my head around the relationship between the pt_regs, pt_regs_subarch, uml_pt_regs and sigcontext. (i.e. what they contain and what they're used for.) - WTF is happening in arch/um/kernel/frame.c:227 : setup_arch_frame_raw(&raw_si->common.arch, ucontext->uc_mcontext.fpregs, raw_si->common.sr); I can't see how uc_mcontext (which is of type "struct sigcontext") contains an fpregs member on /any/ architecture, even i386. gcc certainly thinks it doesn't have an fpregs member on alpha :( - Probably a lot more, but I'll try to harass this list only after I've spent a while trying to work things out myself. Some of the problems (and implicit i386-isms) that I've noticed in UML already are: - Alpha system calls don't just return one value, they return two. A lot of system calls also seem to take advantage of this; e.g. there is no __NR_getpid or __NR_getppid, but instead a __NR_getxpid which returns both. - Since Alpha is a 64-bit architecture, there are no *64 system calls either. This also affects other parts of the kernel which use #if to check for Alpha/sparc64/S390/etc to determine whether or not we're on a 64-bit platform. I've worked around this by adding a -D__um_alpha__ to CFLAGS and changing some places which check for __alpha__ to also check for __um_alpha__. This may not be the cleanest way to do things thought :( - I've needed to add a couple of extra (Alpha-specific) "dummy" headers to include/asm-um which just include include their arch/*.h counterparts. - I've also changed asm-um/elf.h to only define ELF_EXEC_PAGESIZE, ELF_CLASS and elf_check_arch if they aren't already defined in archparam. In the case of Alpha, the page size is 8192 (not 4096) and ELF_CLASS is ELFCLASS64 (not ELFCLASS32). Is there any reason why this weren't being defined in some arch-specific way to begin with? - Also, why is elf_check_arch() defined to return (1) in elf.h, whereas 'real' architectures actually check something here? I think that this is a UML bug, as an i386 UML will attempt to run binaries compiled for other platforms. e.g. on a real i386: $ file ./stack_test_alpha ./stack_test_alpha: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped $ ./stack_test_alpha bash: ./stack_test_alpha: cannot execute binary file but a UML running on i386 looks like it's trying to execute it: $ file ./stack_test_alpha ./stack_test_alpha: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), dynamically linked (uses shared libs), not stripped $ ./stack_test_alpha bash: ./stack_test_alpha: Cannot allocate memory Another thing that would make life a lot easier would be being able to cross-compile UML. Unfortunately that would mean some way of getting rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best approach to doing that would be :-/ Cheers, Cameron. |
From: Jeff D. <jd...@ad...> - 2003-12-20 17:16:52
|
On Sat, Dec 20, 2003 at 01:20:32PM +0800, Cameron Patrick wrote: > - I'm having trouble getting my head around the relationship between > the pt_regs, pt_regs_subarch, uml_pt_regs and sigcontext. (i.e. what > they contain and what they're used for.) pt_regs is the UML version of the processor state. It contains, among other things, the register state of the process as either a sigcontext * (in tt mode) or an array (in skas mode). uml_pt_regs is the same thing, basically, except that it can be used by the userspace portions of UML, while pt_regs can only be used by the kernel portions of UML since it is defined in a kernel header. In tt mode, the process register state is stored at the top of the kernel stack in a struct sigcontext by the host kernel's signal delivery code. Anything which manipulates the registers will, in tt mode, refer to that structure through the pointer in the process' pt_regs. pt_regs_subarch is the pt_regs of the underlying architecture. > > - WTF is happening in arch/um/kernel/frame.c:227 : > setup_arch_frame_raw(&raw_si->common.arch, > ucontext->uc_mcontext.fpregs, raw_si->common.sr); > I can't see how uc_mcontext (which is of type "struct sigcontext") > contains an fpregs member on /any/ architecture, even i386. gcc > certainly thinks it doesn't have an fpregs member on alpha :( From /usr/include/asm/sigcontext.h on my laptop: struct sigcontext { ... struct _fpstate * fpstate; ... }; > - Alpha system calls don't just return one value, they return two. A > lot of system calls also seem to take advantage of this; e.g. there is > no __NR_getpid or __NR_getppid, but instead a __NR_getxpid which > returns both. There should be enough flexibility in the EXECUTE_SYSCALL macro to let you handle this. If not, then just mash something in for Alpha, and we'll clean it up later. > > - Since Alpha is a 64-bit architecture, there are no *64 system calls > either. This also affects other parts of the kernel which use #if to > check for Alpha/sparc64/S390/etc to determine whether or not we're on > a 64-bit platform. I've worked around this by adding a -D__um_alpha__ > to CFLAGS and changing some places which check for __alpha__ to also > check for __um_alpha__. This may not be the cleanest way to do things > thought :( This is a problem. There should be a CONFIG_64BITS which all the 64 bit arches set, so we don't have to add #ifdef UML && UML_ALPHA to all these places. > > - I've needed to add a couple of extra (Alpha-specific) "dummy" headers > to include/asm-um which just include include their arch/*.h > counterparts. Fine, we can figure out whether this needs fixing later. > - I've also changed asm-um/elf.h to only define ELF_EXEC_PAGESIZE, > ELF_CLASS and elf_check_arch if they aren't already defined in > archparam. In the case of Alpha, the page size is 8192 (not 4096) > and ELF_CLASS is ELFCLASS64 (not ELFCLASS32). Is there any reason why > this weren't being defined in some arch-specific way to begin with? They should have been. Feel free to send in cleanups like that as you go. > - Also, why is elf_check_arch() defined to return (1) in elf.h, whereas > 'real' architectures actually check something here? I think that this > is a UML bug, as an i386 UML will attempt to run binaries compiled for > other platforms. e.g. on a real i386: Probably because I never bother figuring out what it was really supposed to do. I don't see any reason we can't just steal it from the underlying arch. > Another thing that would make life a lot easier would be being able to > cross-compile UML. Unfortunately that would mean some way of getting > rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best > approach to doing that would be :-/ There was a bit of work in that direction a while back. What I think would be a good way to go is to have a arch_headers rule in the Makefile, which would execute on the target, and generate the headers. They would land in a single directory, which you would then copy over to the build box. The build there would use those headers, or generate them itself if they weren't present. Jeff |
From: Cameron P. <ca...@pa...> - 2003-12-22 04:19:54
|
On Sat, Dec 20, 2003 at 12:32:49PM -0500, Jeff Dike wrote: | > setup_arch_frame_raw(&raw_si->common.arch, | > ucontext->uc_mcontext.fpregs, raw_si->common.sr); [...] | | >From /usr/include/asm/sigcontext.h on my laptop: | | struct sigcontext { | ... | struct _fpstate * fpstate; | ... | }; Yeah, but that's fpstate, not fpregs. Looking at it more closely, on i386, uc_mcontext is /not/ of type sigcontext, but mcontext_t, which includes an fpregs member. On alpha, uc_mcontext is a sigcontext, and it has a sc_fpregs member. I'm not sure that that's the appropriate thing to change it to though - I'll have to look to see exactly what it's using it for. | > - Since Alpha is a 64-bit architecture, there are no *64 system calls | > either. This also affects other parts of the kernel which use #if to | > check for Alpha/sparc64/S390/etc to determine whether or not we're on | > a 64-bit platform. I've worked around this by adding a -D__um_alpha__ | > to CFLAGS and changing some places which check for __alpha__ to also | > check for __um_alpha__. This may not be the cleanest way to do things | > thought :( | | This is a problem. There should be a CONFIG_64BITS which all the 64 bit | arches set, so we don't have to add #ifdef UML && UML_ALPHA to all these | places. Okay. It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6 some time and see if that makes this problem disappear. | > cross-compile UML. Unfortunately that would mean some way of getting | > rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best | > approach to doing that would be :-/ | | There was a bit of work in that direction a while back. What I think would | be a good way to go is to have a arch_headers rule in the Makefile, which | would execute on the target, and generate the headers. They would land | in a single directory, which you would then copy over to the build box. | The build there would use those headers, or generate them itself if they | weren't present. Yeah, that sounds sensible. I'll have a shot at munging the Makefiles to do just that. :-) Cheers, Cameron. |
From: Jeff D. <jd...@ad...> - 2003-12-23 00:54:25
|
On Mon, Dec 22, 2003 at 12:19:51PM +0800, Cameron Patrick wrote: > Yeah, but that's fpstate, not fpregs. Oops, nevermind... > Okay. It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6 > some time and see if that makes this problem disappear. It's not there either. I think for now, ifdef those things on something like CONFIG_64BIT_UML, and set that in your config.in. Jeff |
From: BlaisorBlade <bla...@ya...> - 2003-12-23 19:52:07
|
Alle 05:19, luned=EC 22 dicembre 2003, Cameron Patrick ha scritto: > Okay. It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6 > some time and see if that makes this problem disappear. > > | > cross-compile UML. Unfortunately that would mean some way of getting > | > rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best > | > approach to doing that would be :-/ > | > | There was a bit of work in that direction a while back. What I think > | would be a good way to go is to have a arch_headers rule in the Makefil= e, > | which would execute on the target, and generate the headers. They would > | land in a single directory, which you would then copy over to the build > | box. The build there would use those headers, or generate them itself if > | they weren't present. Sorry, I'm giving a look here and it seems that the problem is just for=20 mk_ptregs and mk_sc(since the others include the building kernel includes)= =20 and that they need only the target headers; this could maybe be accomplishe= d=20 just by copying them; and since what we *actually* need seems to be just as= m/=20 headers, this can be accomplished simply by having a kernel tree with the a= sm=20 symlink going to asm-<target arch>(that is much more available than the=20 target machine itself, right?). So, specifying an include path for those=20 files could be just fine, couldn't it? However, if we use your separate rul= e=20 idea, within that we could use either just the headers or the host machine;= =20 so some problems go away(i.e. the kernel tree must match the target machine= 's=20 one for the interested decls). Note: mk_sc includes <signal.h>, which could be a problem. But it seems als= o=20 that we can get away by just including asm/sigcontext.h. Bye =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: BlaisorBlade <bla...@ya...> - 2003-12-21 15:41:16
|
Alle 06:20, sabato 20 dicembre 2003, Cameron Patrick ha scritto: > Hi all, > > I've been looking into porting User-Mode Linux to the alpha. I've made > a start by copying the i386-specific bits into {sys,sysdep,etc}-alpha, > following the porting guide on u-m-l.sf.net (which is sadly out of > date), and generally hacking stuff so that it looked appropriate. > Large portions of the kernel now seem to compile :-D. Are you working on 2.4 or 2.6? I'd suggest the second choice, since otherwise you'll have to duplicate part of the work(recheck patches...). It is true than 2.6 still waits for some patches applied to 2.4, so you may get some more troubles(module loading still doesn't work in the vanilla tree, but search in the archives a few days ago for an up-to-date patch I posted and disable MODVERSIONS). But by the time you finish the porting, I think(or hope) that development will have moved to 2.6. Note: by "vanilla" I mean 2.6 + the 2.6 patch you find on the UML site; 2.6 includes some bits of the UML arch, but it doesn't work and Linus refused patches, so it's confusing. -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: Cameron P. <ca...@pa...> - 2003-12-22 04:15:34
|
On Sun, Dec 21, 2003 at 04:44:38PM +0100, BlaisorBlade wrote: | Are you working on 2.4 or 2.6? I'd suggest the second choice, since otherwise | you'll have to duplicate part of the work(recheck patches...). It is true | than 2.6 still waits for some patches applied to 2.4, so you may get some | more troubles(module loading still doesn't work in the vanilla tree, but | search in the archives a few days ago for an up-to-date patch I posted and | disable MODVERSIONS). But by the time you finish the porting, I think(or | hope) that development will have moved to 2.6. I've been working on 2.4 so far. I'm not running 2.6 on any machine at all ATM, and from the sounds of this mailing list, you can't run a 2.6 UML on a 2.4 host? Also, the Alpha is running Debian woody at the moment, and I'm not sure how well that copes with a 2.6 kernel. But thanks for the advice, and I will look at porting 2.6 since it would probably be less painful in the long run. Cameron. |
From: Matt Z. <md...@de...> - 2003-12-22 04:29:55
|
On Mon, Dec 22, 2003 at 12:15:23PM +0800, Cameron Patrick wrote: > I've been working on 2.4 so far. I'm not running 2.6 on any machine at > all ATM, and from the sounds of this mailing list, you can't run a 2.6 > UML on a 2.4 host? Also, the Alpha is running Debian woody at the > moment, and I'm not sure how well that copes with a 2.6 kernel. It requires that the usual handful of packages be updated (procps, util-linux, module-init-tools/modutils, etc.). -- - mdz |
From: BlaisorBlade <bla...@ya...> - 2003-12-24 17:34:38
|
Alle 05:29, luned=EC 22 dicembre 2003, Matt Zimmerman ha scritto: > On Mon, Dec 22, 2003 at 12:15:23PM +0800, Cameron Patrick wrote: > > I've been working on 2.4 so far. I'm not running 2.6 on any machine at > > all ATM, and from the sounds of this mailing list, you can't run a 2.6 > > UML on a 2.4 host? You can. BUT if you apply the Ingo Molnar patches, THEN you can't. Both his= =20 combo or his host-skas patch create this incompatibility, only for skas mod= e. =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |