Ivan Maidanski
2011-02-09 21:04:36 UTC
Hi Elijah,
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
ChangeLog entries:
2011-02-09 Ivan Maidanski <***@mail.ru>
* src/atomic_ops.c (AO_USE_NO_SIGNALS, AO_USE_NANOSLEEP): New
macros.
* src/atomic_ops.c (AO_USE_WIN32_PTHREADS): Imply
AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Don't include signal.h if AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Include time.h if AO_USE_NANOSLEEP.
* src/atomic_ops.c (AO_locks, AO_pause): Reformat the code.
* src/atomic_ops.c (AO_pause): Use nanosleep() if
AO_USE_NANOSLEEP.
* src/atomic_ops.c (all_sigs, initialized,
AO_compare_and_swap_emulation,
AO_compare_double_and_swap_double_emulation): Use
AO_USE_NO_SIGNALS instead of AO_USE_WIN32_PTHREADS.
Regards.
definition
Why not to leave MACH_TYPE as-is (e.g. "I386", etc.)? NaCl is a kind of
OS not
port is
for
me.
If mmap is supported by NaCl then it might be possible to support
USE_M[UN]MAP.
code?
Protection
supported.
would
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/) ... can you
point
(For convenience, I have a recent snapshot as a tarball which I use for
my
than
segfault to
as
ok,as
fixed
- if threads-support is on then is it possible to use
USE_GET_STACKBASE_FOR_MAIN?;
- is it possible to LINUX_STACKBOTTOM (if we are on real Linux)?
- for NaCl on Cygwin, it might be possible to use
GC_get_[main_]stack_base
x86-64
port
they
ever
code
shared
shared
should be
subsystem? (I guess this should be treated as GC public API)
Of course, use STATIC or static where possible (all STATIC symbols start
with
a
look
port
at
included a
http://code.google.com/p/naclports/)
is
signals;
NaCl,
too.
we
version?
benefit
I've ported libatomic_ops to NaCl.
The patch attached.
NaCl target requires -DAO_USE_NO_SIGNALS -DAO_USE_NANOSLEEP
ChangeLog entries:
2011-02-09 Ivan Maidanski <***@mail.ru>
* src/atomic_ops.c (AO_USE_NO_SIGNALS, AO_USE_NANOSLEEP): New
macros.
* src/atomic_ops.c (AO_USE_WIN32_PTHREADS): Imply
AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Don't include signal.h if AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Include time.h if AO_USE_NANOSLEEP.
* src/atomic_ops.c (AO_locks, AO_pause): Reformat the code.
* src/atomic_ops.c (AO_pause): Use nanosleep() if
AO_USE_NANOSLEEP.
* src/atomic_ops.c (all_sigs, initialized,
AO_compare_and_swap_emulation,
AO_compare_double_and_swap_double_emulation): Use
AO_USE_NO_SIGNALS instead of AO_USE_WIN32_PTHREADS.
Regards.
Fri, 14 Jan 2011 15:36:34 -0800 ÐÉÓØÍÏ ÏÔ Elijah Taylor <
detailHi Ivan,
Thanks for taking a look, I'm pleasantly surprised by the level of
Thanks for taking a look, I'm pleasantly surprised by the level of
- the patch in naclports repository contains a typo in a macro
(MAC_TYPE -> MACH_TYPE);
Oops, will fix.a kind of machine hardware.
Is eg. I386 defined for x86?
Also, please add a mapping comment in gcconfig.h (around "Feel free to
addIs eg. I386 defined for x86?
Also, please add a mapping comment in gcconfig.h (around "Feel free to
more clauses here").
than- the patch in naclports repository looks more suitable for gc v72
that for mono/libgc;
This patch is meant to be applied to vanilla gc6.8. The mono/libgcalready patched directly into mono's code repository.
Yes, I only meant the vanilla gc6.8 patch contains some more code (eg,PARALLEL_MARK) not present in mono/libgc.
macro
Though- gc_pthread_redirects.h (which is a public one) should not test NACL
(or, at least, while less desirable, it should be prefixed with GC_);
Ok, makes sense, I think I didn't realize this was a public header.that explains why I had to add a test for __native_client__ (which is
defined in our toolchain). I'll fix this.
USE_M[UN]MAP,defined in our toolchain). I'll fix this.
- it's not clear why you need to explicitly undef STACK_GRAN,
etc. in gcconfig.h;
I'll do some investigation, but IIRC these were needed at one point forThere's a good chance these may be unnecessary and vestigial.
There should none "undef" (no other target undefining them).If mmap is supported by NaCl then it might be possible to support
USE_M[UN]MAP.
- is MPROTECT_VDB supported or not?;
Is MPROTECT_VDB equivalent to catching protection violations in the GCIf so, then no, we don't support anything like that right now.
violation in NaCl == instant death.
Ok, so MPROTECT_VDB (i.e., incremental/generation collection) is notsupported.
- if you you want to port gc72 please use the recent CVS snapshot (it
be easier to me to review and commit it);
I've been grabbing source fromhttp://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/
me
toto where I should be getting the latest? It's not immediately obvious
me.
http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/(For convenience, I have a recent snapshot as a tarball which I use for
project -
http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2)
HEURISTIC1http://www.ivmaisoft.com/_mirror/hpl/bdwgc-7_2alpha5-20110107.tar.bz2)
- not sure that HEURISTIC1 really works reliably there (in short,
means you treat stack pointer at GC_init call as stack bottom - is it
guaranteed that GC_init call is always done at higher stack addresses
guaranteed that GC_init call is always done at higher stack addresses
any other GC call);
HEURISTIC2 will definitely not work for us as it wants to use adetect running over the stack. I've set STACK_GRAN to 64K, so as long
the stack doesn't grow beyond that size before GC_init, we should be
right? The stack for the main thread right now in NaCl lives at a
address usually, but that isn't guaranteed for all future time, so I'd
prefer not to hard code magic numbers here.
No, HEURISTIC2 won't work without signals, but there are otherprefer not to hard code magic numbers here.
- if threads-support is on then is it possible to use
USE_GET_STACKBASE_FOR_MAIN?;
- is it possible to LINUX_STACKBOTTOM (if we are on real Linux)?
- for NaCl on Cygwin, it might be possible to use
based on __asm__ ("%fs:4").
platforms- is the GC port compilable (and working) on other (non-Linux)
(eg., Cygwin);
Native Client is meant to be portable, so it should run on any x86 ormachine once it's built. In terms of building, I haven't built this gc
personally on Mac or Windows, but I just checked our build bot logs and
seem to be building ok on Mac and in Cygwin.
So, eg. DARWIN, GC_DARWIN_THREADS, WIN32, CYGWIN, GC_WIN32_THREADS won'tbe defined when building NaCl, right?
Is GC_LINUX_THREADS defined when building NaCl with multi-threaded
support?Is GC_LINUX_THREADS defined when building NaCl with multi-threaded
I have very little knowledge of NaCl - could you briefly explain what
doesstand for NaCl portability - is it possible to call Win32 API if I'm
compilingon Cygwin or should I use the NaCl API (and, thus, the compiled binary
codewill run on any x86 target)?
If NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc shouldn't be
definedIf NaCl is some kind of OS then LINUX, DARWIN, WIN32, etc shouldn't be
(even if __linux__ defined) if NACL.
Same for GC_xxx_THREADS - I think GC_NACL_THREADS could be defined
instead ofSame for GC_xxx_THREADS - I think GC_NACL_THREADS could be defined
GC_LINUX_THREADS, etc.
I also think that I386 and X86_64 should stay defined for respectively
theI also think that I386 and X86_64 should stay defined for respectively
corresponding CPU type (I guess it is already for NaCl but i haven't
checkedyet)
I think there should be 2 ifdef NACL define OS_TYPE "NACL" ... sections
(oneI think there should be 2 ifdef NACL define OS_TYPE "NACL" ... sections
for every supported CPU).
shoud- for non-static GC-internal symbols use GC_ prefix (eg. for
nacl_thread_parked);
- define SIG_SUSPEND to -1 (instead of 0) as it is returned by
GC_get_suspend_signal;
- GC functions called from NaCl it self (eg, nacl_pre_syscall_hook)
nacl_thread_parked);
- define SIG_SUSPEND to -1 (instead of 0) as it is returned by
GC_get_suspend_signal;
- GC functions called from NaCl it self (eg, nacl_pre_syscall_hook)
be tagged with some attribute (like public GC functions are) both for
readability and to prevent that symbols stripping when compiled as a
lib with -DGC_DLL);
I'll address these issues. (note that NaCl currently doesn't supportlibs yet so your dll example won't happen, but I agree that these
treated like other public GC functions)
Ok. But what is eg. nacl_pre_syscall_hook() - a callback from the NaClsubsystem? (I guess this should be treated as GC public API)
Of course, use STATIC or static where possible (all STATIC symbols start
GC_, while static typically not).
More tips: use GC_INNER and GC_EXTERN for internal global variables; use
GC_INNER for internal functions.
whichMore tips: use GC_INNER and GC_EXTERN for internal global variables; use
GC_INNER for internal functions.
- libatomic_ops does not use signals API (except for CAS emulation
is
but Inot used for x86/x64).
I think I saw sigprocmask and related functions and assumed the worst,see now that's windows code. Looking at the x86 variants it looks like
NaCl port of libatomic_ops is probably not going to be too bad. I'll
into this eventually.
Most probably, it work w/o any porting afforts but it would be good toatomic_ops.c (similar to what I did for Win32-pthreads targets - see
AO_USE_WIN32_PTHREADS, I guess you should add AO_USE_NACL macro testing
inAO_USE_WIN32_PTHREADS, I guess you should add AO_USE_NACL macro testing
that file (looks easy to add). I think it's worth doing first (and submit
me aseparate patch for libatomics_op when done).
What's about GC_HAVE_BUILTIN_BACKTRACE and GC_CAN_SAVE_CALL_STACKS? At
least,What's about GC_HAVE_BUILTIN_BACKTRACE and GC_CAN_SAVE_CALL_STACKS? At
gc.h should be consistent with the GC implementation (I mean eg. if
GC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be defined in
gc.hGC_HAVE_BUILTIN_BACKTRACE not supported then it shouldn't be defined in
regardless of __linux__, _MSC_VER, etc. provided __native_client__).
Same forGC_ADD_CALLER, GC_RETURN_ADDR.
Regards.
probably worth doing it. I would still love to hear anyone chime in on
theRegards.
PS. Let me not do the benefits analysis (probably someone else can do
this).
Well, if the gc7.2 port is as easy as it's looking now, I think it'sthis).
probably worth doing it. I would still love to hear anyone chime in on
benefits of gc7.2 vs 6.8 though
NativeRegards.
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Thu, 13 Jan 2011 10:21:03 -0800 Elijah Taylor <
Hi GC folks,
I saw a little chatter in the archives related to porting libgc to
I saw a little chatter in the archives related to porting libgc to
Client, so I joined this list to share some details. I'm the engineer
Google who ported of libgc to Native Client for Mono. I've also
http://code.google.com/p/naclports/ (
. This version will be available to
versions,users that want to use libgc as part of their Native Client projects.
Before porting gc6.8 I had attempted to port one of the newer
gc7.2alpha4, but ran into snags. The largest snag right now I think
that
effort ingc 7+ includes libatomic_ops which will require some non-trivial
order to work under Native Client. Most notably we don't support
that was the biggest effort in porting libgc in the first place for
and I assume that will require the most work in porting libatomic_ops
Can someone give me the high level details of what kind of things
might be missing if we only support gc6.8 instead of the latest
Because of our thread stopping implementation, we may not even
from
some of the newer features. I just wanted to get a sense of what the
benefits are of getting a newer version available for users.
benefits are of getting a newer version available for users.
-Elijah