Re: 32/64bit KSE issues?
on 31/03/2007 05:23 Daniel Eischen said the following: On Fri, 30 Mar 2007, David E. Cross wrote: I recently ran into a problem where the 32bit JVM won't run on a 64bit host. I, and at least one other person in -java thinks it has to do with 32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is this still the issue? Could someone point me in the general direction of the specifics of the problem (if they exist, if not, I may try to create a simpler test case then java)? I tried a few searches, but nothing matching what I remembered came up. No, you can't run 32-bit libpthread on 64-bit kernel. There are no compatiblity hooks in the kernel to handle 32-bit kse interfaces. It is really too messy to provide it. Daniel, maybe you can send a followup to the following ? http://www.freebsd.org/cgi/query-pr.cgi?pr=110655 Given that 32-bit libthr also doesn't work on 64-bit kernel, the only option is to map thread libs to libc_r via libmap32.conf. BTW, next time there is a poll about retiring libc_r please count me against for precisely this reason. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Fri, Mar 30, 2007 at 09:21:33PM +0400, Yar Tikhiy wrote: [...] If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. [...] By the way, I found myself w/o a Solaris account, but I was able to build Solaris sed in FreeBSD quickly from the OpenSolaris sources. All it took was downloading the following files: http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed.h http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed0.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed1.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbhead/regexp.h and issuing this command: cc -I. -o sed sed*.c Voila! (Their regexp.h offers definitions of its functions, not just their prototypes, which made my task very easy.) Perhaps other basic tools from Solaris could be built in this way for the purpose of testing, too, in case one needs them but has no Solaris account at hand. Another $0.02 from yours truly. :-) -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thread local storage not working with -fPIC and shared objects
On Sat, 31 Mar 2007 04:26:23 +0200
Pieter de Goeje [EMAIL PROTECTED] wrote:
Hello List,
I have these files:
--- loader.cpp ---
#include stdio.h
#include tls.h
int main() {
tls = 0;
printf(%d\n, tls);
}
--- tls.cpp ---
#include tls.h
int __thread tls;
--- tls.h ---
extern __thread int tls;
When I compile them like this:
c++ -fPIC -o tls.so tls.cpp -shared
c++ -fPIC -o loader loader.cpp tls.so
And run the resulting program, I get:
[EMAIL PROTECTED]:~/projects/misc/tls ./loader
/libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in
non-PLT relocations
When I omit -fPIC, it runs fine. But I need fPIC for the shared
object on amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it
ran fine (with fPIC).
Much to my surprise however, a particularly large application I'm
working on did compile run on FreeBSD/amd64 using -fpic (lowercase)
and gcc 4.3. Trying -fpic on FreeBSD/i386 resulted in failure.
FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp
threadprivate()) support in gcc 4.3.
The workaround I found on FreeBSD/amd64 was linking the main
executable with -fno-PIC, or building everything with -fpic. (both
workarounds didn't work on FreeBSD/i386)
I would be grateful if someone could shed some light on this.
There is no reason whatsoever to compile main binary code with -f[pP]ic.
Executables are not shared libraries and stuffing position independent
code into them makes no sense.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: 32/64bit KSE issues?
David E. Cross wrote: I recently ran into a problem where the 32bit JVM won't run on a 64bit host. I, and at least one other person in -java thinks it has to do with 32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is this still the issue? Could someone point me in the general direction of the specifics of the problem (if they exist, if not, I may try to create a simpler test case then java)? I tried a few searches, but nothing matching what I remembered came up. The KSE system calls have not been emulated in the 32 bit emulation layer. it tries to save a 64 bit stack frame where it needs to save a 32 bit stack frame. try run libthr for now. fixing the emulation layer is in my to do list but I'm busy with RealWork (TM) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 32/64bit KSE issues?
On Saturday 31 March 2007 03:16, Andriy Gapon wrote: on 31/03/2007 05:23 Daniel Eischen said the following: On Fri, 30 Mar 2007, David E. Cross wrote: I recently ran into a problem where the 32bit JVM won't run on a 64bit host. I, and at least one other person in -java thinks it has to do with 32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is this still the issue? Could someone point me in the general direction of the specifics of the problem (if they exist, if not, I may try to create a simpler test case then java)? I tried a few searches, but nothing matching what I remembered came up. No, you can't run 32-bit libpthread on 64-bit kernel. There are no compatiblity hooks in the kernel to handle 32-bit kse interfaces. It is really too messy to provide it. Daniel, maybe you can send a followup to the following ? http://www.freebsd.org/cgi/query-pr.cgi?pr=110655 Given that 32-bit libthr also doesn't work on 64-bit kernel, the only option is to map thread libs to libc_r via libmap32.conf. BTW, next time there is a poll about retiring libc_r please count me against for precisely this reason. I plan on making sure full 32-bit compat exists for both libthr and libpthread and backporting it to 6.x for work. Very few things are too hard to wrap with a 32-bit shim. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On 2007-03-31 15:02, Yar Tikhiy [EMAIL PROTECTED] wrote: On Fri, Mar 30, 2007 at 09:21:33PM +0400, Yar Tikhiy wrote: [...] If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. [...] By the way, I found myself w/o a Solaris account, but I was able to build Solaris sed in FreeBSD quickly from the OpenSolaris sources. All it took was downloading the following files: http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed.h http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed0.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed1.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbhead/regexp.h and issuing this command: cc -I. -o sed sed*.c Voila! (Their regexp.h offers definitions of its functions, not just their prototypes, which made my task very easy.) Perhaps other basic tools from Solaris could be built in this way for the purpose of testing, too, in case one needs them but has no Solaris account at hand. Nice. With very minor modifications, it may be possible to build more of the OpenSolaris tools on FreeBSD. For instance, the only change I had to make to build the Solaris version of cat(1) on FreeBSD was: %%% --- cat.c.orig Sat Mar 31 20:03:26 2007 +++ cat.c Sat Mar 31 20:02:07 2007 @@ -43,7 +43,9 @@ #include unistd.h #include sys/mman.h +#ifdef __FreeBSD_version #include widec.h +#endif #include wctype.h #include limits.h #include libintl.h %%% The Solaris version of cat(1) calls textdomain() and gettext() explicitly, so I also had to use libintl.so from the Ports to compile it successfully: $ cc -I/usr/local/include cat.c -L/usr/local/lib -lintl But it does work, AFAICT. I haven't tried localized message support yet, but this will take a bit more effort :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 32/64bit KSE issues?
On Sat, 31 Mar 2007, John Baldwin wrote: On Saturday 31 March 2007 03:16, Andriy Gapon wrote: on 31/03/2007 05:23 Daniel Eischen said the following: On Fri, 30 Mar 2007, David E. Cross wrote: I recently ran into a problem where the 32bit JVM won't run on a 64bit host. I, and at least one other person in -java thinks it has to do with 32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is this still the issue? Could someone point me in the general direction of the specifics of the problem (if they exist, if not, I may try to create a simpler test case then java)? I tried a few searches, but nothing matching what I remembered came up. No, you can't run 32-bit libpthread on 64-bit kernel. There are no compatiblity hooks in the kernel to handle 32-bit kse interfaces. It is really too messy to provide it. [ ... ] I plan on making sure full 32-bit compat exists for both libthr and libpthread and backporting it to 6.x for work. Very few things are too hard to wrap with a 32-bit shim. Not according to peter@ ;-) But if you can do it, that'd be great. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Deny system call using ptrace
Hi, I'm trying to create sort of user-space access control system based on allowing/denying syscalls. I was able (after a few problems) to start ptracing program, stop at every enter/exit from system call, inspect arguments etc. What I'm however trying to do, is denying access to syscalls. In linux I was able to do this by changing register eax to SYS_getpid or other safe system call using ptrace(PT_SETREGS,..). Problem is, that FreeBSD kernel seems to ignore changed register, and execute original system call. If I do PT_SETREGS and right after that PT_GETREGS, I can see that register was changed, so that should be ok. It is possible I'm missing something, or there is another option. I'd be grateful for any advice or idea. Thanks, S.O. signature.asc Description: OpenPGP digital signature
Re: Thread local storage not working with -fPIC and shared objects
On zaterdag 31 maart 2007, Alexander Kabaev wrote: There is no reason whatsoever to compile main binary code with -f[pP]ic. Executables are not shared libraries and stuffing position independent code into them makes no sense. You are right ofcourse. However it doesn't explain why it won't work. - Pieter de Goeje ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thread local storage not working with -fPIC and shared objects
On zaterdag 31 maart 2007, Garrett Cooper wrote:
Pieter de Goeje wrote:
Hello List,
I have these files:
--- loader.cpp ---
#include stdio.h
#include tls.h
int main() {
tls = 0;
printf(%d\n, tls);
}
--- tls.cpp ---
#include tls.h
int __thread tls;
--- tls.h ---
extern __thread int tls;
When I compile them like this:
c++ -fPIC -o tls.so tls.cpp -shared
c++ -fPIC -o loader loader.cpp tls.so
And run the resulting program, I get:
[EMAIL PROTECTED]:~/projects/misc/tls ./loader
/libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in non-PLT
relocations
When I omit -fPIC, it runs fine. But I need fPIC for the shared object on
amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it ran fine (with
fPIC).
Much to my surprise however, a particularly large application I'm working
on did compile run on FreeBSD/amd64 using -fpic (lowercase) and gcc
4.3. Trying -fpic on FreeBSD/i386 resulted in failure.
FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp
threadprivate()) support in gcc 4.3.
The workaround I found on FreeBSD/amd64 was linking the main executable
with -fno-PIC, or building everything with -fpic. (both workarounds
didn't work on FreeBSD/i386)
I would be grateful if someone could shed some light on this.
Regards,
Pieter de Goeje
Pieter,
Did you know that -fPIC and -fpic aren't the same? From
I was aware of that, however:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Code-Gen-Options.html#Code-Gen-Options:
|-fpic|
Generate position-independent code (PIC) suitable for use in a
shared library, if supported for the target machine. Such code
accesses all constant addresses through a global offset table (GOT).
The dynamic loader resolves the GOT entries when the program starts
(the dynamic loader is not part of GCC; it is part of the operating
system). If the GOT size for the linked executable exceeds a
machine-specific maximum size, you get an error message from the
linker indicating that -fpic does not work; in that case, recompile
with -fPIC instead. (These maximums are 8k on the SPARC and 32k on
the m68k and RS/6000. The 386 has no such limit.)
Position-independent code requires special support, and therefore
works only on certain machines. For the 386, GCC supports PIC for
System V but not for the Sun 386i. Code generated for the IBM
RS/6000 is always position-independent.
|-fPIC|
If supported for the target machine, emit position-independent code,
suitable for dynamic linking and avoiding any limit on the size of
the global offset table. This option makes a difference on the m68k,
PowerPC and SPARC.
tells me that there should not be a difference between the two on the AMD64
arch. Apparently there is...
Position-independent code requires special support, and therefore
works only on certain machines.
Cheers,
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
