From: Antoine M. <an...@na...> - 2005-12-27 17:53:50
|
FYI, on amd64 hosts, using vanilla 2.6.15-rc7, then applying latest sf.net patches gives: make ARCH=3Dum vmlinux (...) CC arch/um/kernel/skas/process_kern.o arch/um/kernel/skas/process_kern.c: In function =A1copy_thread_skas=A2: arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2 h= as no member named =A1tls_array=A2 arch/um/kernel/skas/process_kern.c:198:2: warning: #warning Need to look up userspace_pid by cpu arch/um/kernel/skas/process_kern.c:204:2: warning: #warning Need to look up userspace_pid by cpu arch/um/kernel/skas/process_kern.c:211:2: warning: #warning need to loop over userspace_pids in kill_off_processes_skas make[2]: *** [arch/um/kernel/skas/process_kern.o] Error 1 make[1]: *** [arch/um/kernel/skas] Error 2 make: *** [arch/um/kernel] Error 2 Antoine |
From: Antoine M. <an...@na...> - 2005-12-27 18:32:08
|
On Tue, 2005-12-27 at 17:53 +0000, Antoine Martin wrote: > FYI, on amd64 hosts, using vanilla 2.6.15-rc7, then applying latest > sf.net patches gives: >=20 make ARCH=3Dum SUBARCH=3Di386 (...) CC arch/um/os-Linux/process.o make[1]: *** No rule to make target `arch/um/os-Linux/sigio.s', needed by `arch/um/os-Linux/sigio.o'. Stop. make: *** [arch/um/os-Linux] Error 2 > make ARCH=3Dum vmlinux > (...) > CC arch/um/kernel/skas/process_kern.o > arch/um/kernel/skas/process_kern.c: In function =A1copy_thread_skas=A2: > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:127: error: =A1struct arch_thread=A2= has > no member named =A1tls_array=A2 > arch/um/kernel/skas/process_kern.c:198:2: warning: #warning Need to loo= k > up userspace_pid by cpu > arch/um/kernel/skas/process_kern.c:204:2: warning: #warning Need to loo= k > up userspace_pid by cpu > arch/um/kernel/skas/process_kern.c:211:2: warning: #warning need to loo= p > over userspace_pids in kill_off_processes_skas > make[2]: *** [arch/um/kernel/skas/process_kern.o] Error 1 > make[1]: *** [arch/um/kernel/skas] Error 2 > make: *** [arch/um/kernel] Error 2 >=20 >=20 > Antoine |
From: Jeff D. <jd...@ad...> - 2006-01-01 03:12:49
|
On Tue, Dec 27, 2005 at 06:31:43PM +0000, Antoine Martin wrote: > On Tue, 2005-12-27 at 17:53 +0000, Antoine Martin wrote: > > FYI, on amd64 hosts, using vanilla 2.6.15-rc7, then applying latest > > sf.net patches gives: > > > make ARCH=um SUBARCH=i386 > (...) > CC arch/um/os-Linux/process.o > make[1]: *** No rule to make target `arch/um/os-Linux/sigio.s', needed > by `arch/um/os-Linux/sigio.o'. Stop. > make: *** [arch/um/os-Linux] Error 2 A stupid omission - fixed now. Jeff |
From: Antoine M. <an...@na...> - 2006-01-01 20:01:06
|
On Sat, 2005-12-31 at 23:04 -0500, Jeff Dike wrote: > On Tue, Dec 27, 2005 at 06:31:43PM +0000, Antoine Martin wrote: > > On Tue, 2005-12-27 at 17:53 +0000, Antoine Martin wrote: > > > FYI, on amd64 hosts, using vanilla 2.6.15-rc7, then applying latest > > > sf.net patches gives: > > > > > make ARCH=um SUBARCH=i386 > > (...) > > CC arch/um/os-Linux/process.o > > make[1]: *** No rule to make target `arch/um/os-Linux/sigio.s', needed > > by `arch/um/os-Linux/sigio.o'. Stop. > > make: *** [arch/um/os-Linux] Error 2 > > A stupid omission - fixed now. ok, I got passed this but now I get this error (I've seen it before) make ARCH=um vmlinux (or make SUBARCH=i386 ARCH=um vmlinux) (...) CC arch/um/os-Linux/tls.o arch/um/os-Linux/tls.c: In function `os_set_thread_area': arch/um/os-Linux/tls.c:22: error: dereferencing pointer to incomplete type arch/um/os-Linux/tls.c: In function `os_get_thread_area': arch/um/os-Linux/tls.c:36: error: dereferencing pointer to incomplete type make[1]: *** [arch/um/os-Linux/tls.o] Error 1 make: *** [arch/um/os-Linux] Error 2 Happy new year! Antoine |
From: Blaisorblade <bla...@ya...> - 2006-01-03 19:38:34
|
On Sunday 01 January 2006 21:00, Antoine Martin wrote: > On Sat, 2005-12-31 at 23:04 -0500, Jeff Dike wrote: > > On Tue, Dec 27, 2005 at 06:31:43PM +0000, Antoine Martin wrote: > > > On Tue, 2005-12-27 at 17:53 +0000, Antoine Martin wrote: > > > > FYI, on amd64 hosts, using vanilla 2.6.15-rc7, then applying latest > > > > sf.net patches gives: > > > > > > make ARCH=um SUBARCH=i386 > > > (...) > > > CC arch/um/os-Linux/process.o > > > make[1]: *** No rule to make target `arch/um/os-Linux/sigio.s', needed > > > by `arch/um/os-Linux/sigio.o'. Stop. > > > make: *** [arch/um/os-Linux] Error 2 > > A stupid omission - fixed now. > ok, I got passed this but now I get this error (I've seen it before) > make ARCH=um vmlinux (or make SUBARCH=i386 ARCH=um vmlinux) > (...) > CC arch/um/os-Linux/tls.o > arch/um/os-Linux/tls.c: In function `os_set_thread_area': > arch/um/os-Linux/tls.c:22: error: dereferencing pointer to incomplete > type > arch/um/os-Linux/tls.c: In function `os_get_thread_area': > arch/um/os-Linux/tls.c:36: error: dereferencing pointer to incomplete > type > make[1]: *** [arch/um/os-Linux/tls.o] Error 1 > make: *** [arch/um/os-Linux] Error 2 Tested with enabling / disabling MODE_TT/SKAS? I don't remember the config I was using when working on the patch, I guess I had both enabled. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Antoine M. <an...@na...> - 2006-01-06 17:12:25
|
> > CC arch/um/os-Linux/tls.o > > arch/um/os-Linux/tls.c: In function `os_set_thread_area': > > arch/um/os-Linux/tls.c:22: error: dereferencing pointer to incomplete > > type > > arch/um/os-Linux/tls.c: In function `os_get_thread_area': > > arch/um/os-Linux/tls.c:36: error: dereferencing pointer to incomplete > > type > > make[1]: *** [arch/um/os-Linux/tls.o] Error 1 > > make: *** [arch/um/os-Linux] Error 2 > > Tested with enabling / disabling MODE_TT/SKAS? I don't remember the config I > was using when working on the patch, I guess I had both enabled. > Actually disabling TT fixed it - so this skas only for now (not a problem) Now for 2.6.15 - here was the output (before I disabled TT) slightly different (not the same environment & patches): CC arch/um/os-Linux/tls.o arch/um/os-Linux/tls.c:48: error: syntax error before "get_thread_area" arch/um/os-Linux/tls.c:48: warning: type defaults to `int' in declaration of `_syscall1' arch/um/os-Linux/tls.c:48: warning: function declaration isn't a prototype arch/um/os-Linux/tls.c:48: warning: data definition has no type or storage class arch/um/os-Linux/tls.c:49: error: syntax error before "set_thread_area" arch/um/os-Linux/tls.c:49: warning: type defaults to `int' in declaration of `_syscall1' arch/um/os-Linux/tls.c:49: warning: function declaration isn't a prototype arch/um/os-Linux/tls.c:49: warning: data definition has no type or storage class arch/um/os-Linux/tls.c:51: warning: "struct user_desc" declared inside parameter list arch/um/os-Linux/tls.c:51: warning: its scope is only this definition or declaration, which is probably not what you want arch/um/os-Linux/tls.c: In function `do_set_thread_area_tt': arch/um/os-Linux/tls.c:55: warning: implicit declaration of function `set_thread_area' arch/um/os-Linux/tls.c: At top level: arch/um/os-Linux/tls.c:62: warning: "struct user_desc" declared inside parameter list arch/um/os-Linux/tls.c: In function `do_get_thread_area_tt': arch/um/os-Linux/tls.c:66: warning: implicit declaration of function `get_thread_area' |
From: Antoine M. <an...@na...> - 2006-01-06 17:41:40
|
Failed right at the end... (TT disabled) LD .tmp_vmlinux1 arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': : undefined reference to `indirect_set_thread_area' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make: *** [.tmp_kallsyms1.S] Error 1 Antoine |
From: Antoine M. <an...@na...> - 2006-01-16 16:45:28
|
On Fri, 2006-01-06 at 17:41 +0000, Antoine Martin wrote: > Failed right at the end... (TT disabled) > > LD .tmp_vmlinux1 > arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': > : undefined reference to `indirect_set_thread_area' Tried again today, problems: * static build fails during linking stage * skas build fails as above (the indirect_set_thread_area is only defined if TT mode is on but it is used even if TT mode is off) Antoine |
From: D. B. <db...@en...> - 2006-01-16 17:11:23
Attachments:
signature.asc
tls_no_tt.patch
|
for the second problem try the attached patch of a patch. Antoine Martin wrote: > On Fri, 2006-01-06 at 17:41 +0000, Antoine Martin wrote: > >> Failed right at the end... (TT disabled) >> >> LD .tmp_vmlinux1 >> arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': >> : undefined reference to `indirect_set_thread_area' >> > Tried again today, problems: > * static build fails during linking stage > * skas build fails as above (the indirect_set_thread_area is only > defined if TT mode is on but it is used even if TT mode is off) > > Antoine > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Antoine M. <an...@na...> - 2006-01-16 17:18:44
|
Thanks, that fixes it. On Mon, 2006-01-16 at 12:10 -0500, D. Bahi wrote: > for the second problem try the attached patch of a patch. > > Antoine Martin wrote: > > On Fri, 2006-01-06 at 17:41 +0000, Antoine Martin wrote: > > > >> Failed right at the end... (TT disabled) > >> > >> LD .tmp_vmlinux1 > >> arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': > >> : undefined reference to `indirect_set_thread_area' > >> > > Tried again today, problems: > > * static build fails during linking stage > > * skas build fails as above (the indirect_set_thread_area is only > > defined if TT mode is on but it is used even if TT mode is off) > > > > Antoine > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > User-mode-linux-user mailing list > > Use...@li... > > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > > |
From: Blaisorblade <bla...@ya...> - 2006-01-17 01:09:13
|
On Monday 16 January 2006 18:10, D. Bahi wrote: > for the second problem try the attached patch of a patch. That's bogus, indirect_set_thread_area() should be moved outside #ifdef. It has the needed CHOOSE_MODE (or should have it). At least, don't run with it in TT mode. > Antoine Martin wrote: > > On Fri, 2006-01-06 at 17:41 +0000, Antoine Martin wrote: > >> Failed right at the end... (TT disabled) > >> > >> LD .tmp_vmlinux1 > >> > >> arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': > >> : undefined reference to `indirect_set_thread_area' > > > > Tried again today, problems: > > * static build fails during linking stage > > * skas build fails as above (the indirect_set_thread_area is only > > defined if TT mode is on but it is used even if TT mode is off) > > > > Antoine > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files for problems? Stop! Download the new AJAX search engine that > > makes searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > User-mode-linux-user mailing list > > Use...@li... > > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive http://it.messenger.yahoo.com |
From: D. B. <db...@en...> - 2006-01-17 03:07:00
Attachments:
signature.asc
|
yes, blaise, i read your comment from the november posting to the list in response to this problem reported then and tried it... #ifdef CONFIG_MODE_TT /* This is for use by the tracing thread in special situations (see below). */ static int indirect_set_thread_area_tt(struct user_desc *info) { BUG_ON(os_getpid() !=3D tracing_pid); return os_set_thread_area(info, current->thread.mode.tt.extern_pid); } #endif static inline int indirect_set_thread_area(struct user_desc *info) { if (mode_tt) return indirect_set_thread_area_tt(info); else return 0; } moving the #endif doesn't work because then we have the unresolved reference to the indirect_set_thread_area_tt() -- you have to have the CHOOSE_MODE or CHOOSE_MODE_PROC somewhere in there to macro the unused/undefined mode_tt away. so as to why my patch is bogus ... in load_TLS() you have this check early on if (flags & O_INDIRECT) BUG_ON(CHOOSE_MODE(os_getpid() !=3D tracing_pid, 1)); looks like you blow up if this flag is set and we're not TT so i figured the check here could be removed - ah - but it could be not set it TT mode and you still want to do_set_thread_area.... ret =3D (flags & O_INDIRECT) ? indirect_set_thread_area(&curr->tls): do_set_thread_area(&curr->tls); so replacing the above with ret =3D CHOOSE_MODE_PROC( indirect_set_thread_area, do_set_thread_area, &curr->tls ); would always call indirect_set_thread_area for TT mode and you only want that if it is the tracing_pid else you want do_set_thread_area... oops... my bad. so you'd move the #endif and do/did this instead? static inline int indirect_set_thread_area(struct user_desc *info) { CHOOSE_MODE( return indirect_set_thread_area_tt(info), 0); } right? thanks for the eyes and the time. db Blaisorblade wrote: > On Monday 16 January 2006 18:10, D. Bahi wrote: > =20 >> for the second problem try the attached patch of a patch. >> =20 > > That's bogus, indirect_set_thread_area() should be moved outside #ifdef= =2E It=20 > has the needed CHOOSE_MODE (or should have it). At least, don't run wit= h it=20 > in TT mode. > > =20 >> Antoine Martin wrote: >> =20 >>> On Fri, 2006-01-06 at 17:41 +0000, Antoine Martin wrote: >>> =20 >>>> Failed right at the end... (TT disabled) >>>> >>>> LD .tmp_vmlinux1 >>>> >>>> arch/um/sys-i386/built-in.o(.text+0x2f8e): In function `load_TLS': >>>> : undefined reference to `indirect_set_thread_area' >>>> =20 >>> Tried again today, problems: >>> * static build fails during linking stage >>> * skas build fails as above (the indirect_set_thread_area is only >>> defined if TT mode is on but it is used even if TT mode is off) >>> >>> Antoine >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through lo= g >>> files for problems? Stop! Download the new AJAX search engine that >>> makes searching your log files as easy as surfing the web. DOWNLOAD= >>> SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick= >>> _______________________________________________ >>> User-mode-linux-user mailing list >>> Use...@li... >>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user >>> =20 > > =20 |
From: Blaisorblade <bla...@ya...> - 2006-01-17 14:10:39
|
On Tuesday 17 January 2006 04:06, D. Bahi wrote: > yes, blaise, You've actually got the right meaning of my nick.... I named myself after Blaise Pascal :-) (referring to the Pascal language, indeed)! > i read your comment from the november posting to the list in response to > this problem reported then and tried it... > #ifdef CONFIG_MODE_TT > /* This is for use by the tracing thread in special situations (see > below). */ > static int indirect_set_thread_area_tt(struct user_desc *info) { > BUG_ON(os_getpid() != tracing_pid); > return os_set_thread_area(info, current->thread.mode.tt.extern_pid); > } > > #endif > > static inline int indirect_set_thread_area(struct user_desc *info) { > if (mode_tt) > return indirect_set_thread_area_tt(info); > else > return 0; > } > > moving the #endif doesn't work because then we have the unresolved > reference to the indirect_set_thread_area_tt() -- you have to have the > CHOOSE_MODE or CHOOSE_MODE_PROC somewhere in there to macro the > unused/undefined mode_tt away. Yes, that's missing, it's the correct solution. However in the uploaded patchset I later removed indirect_* altogether. I'm still answering you below to answer your questions. > so as to why my patch is bogus ... in load_TLS() you have this check > early on > > looks like you blow up if this flag is set and we're not TT Ok, but the opposite doesn't hold. Implications are not simmetric, and you're getting this wrong in this mail. > so > i figured the check here could be removed - ah - but it could be > not set it TT mode and you still want to do_set_thread_area.... Parse error + verbosity excess... > ret = (flags & O_INDIRECT) ? > indirect_set_thread_area(&curr->tls): do_set_thread_area(&curr->tls); > > so replacing the above with > > ret = CHOOSE_MODE_PROC( indirect_set_thread_area, > do_set_thread_area, &curr->tls ); > > would always call indirect_set_thread_area for TT mode and you only want > that if Exactly, only if... > it is the tracing_pid No, only when I set O_INDIRECT. Which currently never happens anyway. Actually, O_INDIRECT was never used in the patches I published, I did it another way (instead of actually setting the TLS on the host with O_INDIRECT, that is deferred at context switch time; we only record the thing as unflushed); however, O_INDIRECT could be used only if in TT mode and only from the tracing thread, but even when both conditions are met, the caller is free to avoid O_INDIRECT, like I said. > else you want do_set_thread_area... oops... my bad. > so you'd move the #endif and do/did this instead? > static inline int indirect_set_thread_area(struct user_desc *info) { > CHOOSE_MODE( return indirect_set_thread_area_tt(info), 0); > } > > right? Yes... that was my point. however in current code I replaced that "return 0" with "BUG" so it won't likely work directly. > thanks for the eyes and the time. > > db -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |