Re: The Road to 2.2
On Wed, 2013-05-22 at 00:23 -0400, Noah Lavine wrote: On Sun, May 19, 2013 at 6:02 PM, Ludovic Courtès l...@gnu.org wrote: Andy Wingo wi...@pobox.com skribis: On Sat 18 May 2013 15:44, Noah Lavine noah.b.lav...@gmail.com writes: I have a very small question, based on something I think you said earlier - since the container will be ELF, will we call our files .so now? We certainly can. Is it a good idea though? I’d vote for keeping .go, or at least something different from commonly-used extensions like .so. I don't think it's a big deal, but the reason I asked was that I'm afraid .go will become increasingly popular because of the Go language. .so also sort of hints at native compilation in the future, although that's not a very strong reason to choose it. How about .glc or .glo? But anyway, I don't think we should yield against a competitor. Noah
Deadlock with GC 7.2alpha6 on master
Hello! On a fresh build of ‘master’ (.go not built yet), ../meta/guile -c 1 hangs like this: --8---cut here---start-8--- (gdb) bt #0 0x775d922c in __lll_lock_wait () from /home/ludo/.guix-profile/lib/libpthread.so.0 #1 0x775d503c in _L_lock_974 () from /home/ludo/.guix-profile/lib/libpthread.so.0 #2 0x775d4e8b in pthread_mutex_lock () from /home/ludo/.guix-profile/lib/libpthread.so.0 #3 0x777ffda5 in GC_get_heap_size () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #4 0x77abf5e9 in adjust_gc_frequency (hook_data=optimized out, fn_data=optimized out, data=optimized out) at gc.c:826 #5 0x77acb57c in scm_c_hook_run (hook=0x77dd5140 scm_before_gc_c_hook, data=0x0) at hooks.c:103 #6 0x777f5a9c in GC_try_to_collect_inner () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #7 0x777f6789 in GC_collect_or_expand () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #8 0x777f68ee in GC_allocobj () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #9 0x777fb7df in GC_generic_malloc_inner () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #10 0x777fc754 in GC_generic_malloc_many () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #11 0x778059ce in GC_malloc () from /nix/store/qg8hngsnh4d4zxwyky80v83nxwi0wq56-libgc-7.2alpha6/lib/libgc.so.1 #12 0x77b20474 in scm_words (n_words=7112354, car=7112353) at ../libguile/gc.h:263 #13 scm_i_alloc_struct (vtable_data=0x6c86a0, n_words=n_words@entry=16) at struct.c:442 #14 0x77b20544 in scm_c_make_structv (vtable=vtable@entry=0x6c8690, n_tail=0, n_init=n_init@entry=16, init=init@entry=0x7fff7af0) at struct.c:484 #15 0x77b2065d in scm_make_struct (vtable=0x6c8690, tail_array_size=0x2, init=0x304) at struct.c:559 --8---cut here---end---8--- Could it be that GC_get_heap_size doesn’t attempt to acquire the GC lock with newer versions of libgc, or something like that? Which libgc version do people use? TIA, Ludo’.
Re: Deadlock with GC 7.2alpha6 on master
There’s no such problem with GC 7.2d. Sorry for the noise! Ludo’.
Re: [PATCH 1/6] split linker out of elf module
Hello! Note: I’m just familiarizing with the new code, so I may miss things, and may make mostly superficial comments. Andy Wingo wi...@pobox.com skribis: * module/Makefile.am: * module/system/vm/linker.scm: New file, split out of (system vm elf). * module/system/vm/elf.scm: Remove linking capabilities. * module/language/objcode/elf.scm: Adapt caller to use (system vm linker). * test-suite/tests/linker.test: New test. Looks good. Would be nice to mention variable names too. It seems elf.scm would benefit from byte structures similar to those announced by Taylan on guile-user. That’s more for aesthetics though, and definitely not blocking. Docstrings are lacking in those files. Ludo’.
Re: [PATCH 2/6] ELF refactor and consequent linker simplifications
Andy Wingo wi...@pobox.com skribis: * module/system/vm/elf.scm: Add commentary. (make-elf): Add a constructor similar to make-elf-segment and make-elf-section. (write-elf32-header, write-elf64-header, write-elf-header): Take an elf instead of all the fields separately. (elf-segment, elf-section): Add index property. Adapt constructors accordingly. * module/language/objcode/elf.scm (bytecode-elf): Arrange to set the section indexes when creating ELF sections. * module/system/vm/linker.scm (alloc-segment, relocate-section-header): Arrange to set segment and section indexes. (find-shstrndx): New helper, replaces compute-sections-by-name. Now that sections know their indexes, this is easier. (allocate-elf, write-elf): New helpers, factored out of link-elf. Easier now that sections have indexes. (link-elf): Simplify. Check that the incoming objects have sensible numbers. * test-suite/tests/linker.test: Update to set #:index on the linker objects. Looks good. -(define (fold2 proc ls s0 s1) - (let lp ((ls ls) (s0 s0) (s1 s1)) -(if (null? ls) -(values s0 s1) -(receive (s0 s1) (proc (car ls) s0 s1) - (lp (cdr ls) s0 s1) - (define (fold4 proc ls s0 s1 s2 s3) (let lp ((ls ls) (s0 s0) (s1 s1) (s2 s2) (s3 s3)) (if (null? ls) @@ -236,15 +231,9 @@ (receive (s0 s1 s2 s3) (proc (car ls) s0 s1 s2 s3) (lp (cdr ls) s0 s1 s2 s3) -(define (fold5 proc ls s0 s1 s2 s3 s4) - (let lp ((ls ls) (s0 s0) (s1 s1) (s2 s2) (s3 s3) (s4 s4)) -(if (null? ls) -(values s0 s1 s2 s3 s4) -(receive (s0 s1 s2 s3 s4) (proc (car ls) s0 s1 s2 s3 s4) - (lp (cdr ls) s0 s1 s2 s3 s4) What about moving these to a helper module eventually? Ludo’.
Re: [PATCH 3/6] elf: add accessors for header members that might need relocation
Andy Wingo wi...@pobox.com skribis: * module/system/vm/elf.scm (elf-header-shoff-offset) (elf-section-header-addr-offset, elf-section-header-offset-offset): New accessors. --- module/system/vm/elf.scm | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) OK. Ludo'.
Re: [PATCH 4/6] refactor linker to lay out ELF files and memory in the same way
This goes beyond my ELF capabilities, so can’t really comment on this. Style comments: Andy Wingo wi...@pobox.com skribis: * module/system/vm/linker.scm (make-linker-object): (linker-object-section-symbol): (linker-object-symbols*): Create a symbol to the start of a linker object. Hide it from the external linker-object-symbols* accessor. (segment-kind, count-segments): Sections without SHF_ALLOC don't get segments. (collate-objects-into-segments): Allow for #f segment types. If two sections have the same type and flags, leave them in the same order. (align): Allow for 0 alignment. (add-elf-objects): New helper: puts the ELF data structures (header, segment table, and section table) in sections of their own. This lends a nice clarity and conceptual unity to the linker. Please move the descriptions as docstrings. (relocate-section-header, alloc-objects): Lay out segments with congruent, contiguous addresses, so that we can just mmap the file and if debugging sections that are not in segments are present, they can be lazily paged in if needed by the kernel's VM system. Nice. Could you move this comment in the code? ;; objects ::= list of linker-object -;; = 3 values: ELF header, program headers, objects +;; +;; = 3 values: +;; file size +;; objects with allocated memory address and file offset +;; symbol table +;; (define (allocate-elf objects page-aligned? endianness word-size) What does it do? Ludo’.
Re: CPS thoughts
An update: I just rebased wip-rtl-cps on top of wip-rtl-may-2013 and
pushed. The most interesting thing was how trivial it was: all I had to do
was make a one-line change in how I called `begin-program'.
Best,
Noah
On Wed, May 22, 2013 at 12:33 AM, Noah Lavine noah.b.lav...@gmail.comwrote:
Hello,
On Tue, May 21, 2013 at 3:46 PM, Andy Wingo wi...@pobox.com wrote:
You should have two names: the original ones and the gensyms that come
from tree-il. Creating new gensyms should happen when copying or
fabricating new nodes, as peval does, but in most cases you don't need
to do it, and in any case it can be tricky.
I would take tree-il as the guide here.
I'll look at it, thanks.
I haven't handled source information yet, but to the CPS-RTL compiler
it will look like emitting special instructions, like the tree-il-glil
compiler emits glil-source nodes.
That sounds fairly simple to implement.
This is lambda-properties. You just pass them through, and add them to
the begin-program in the RTL.
Again, this seems relatively simple to do.
Note that wip-rtl-may-2013 and the RTL branches that are under review
for master are slightly different from the ones you have. Their
begin-program has a second argument, the procedure properties, and the
first argument is a label and not a name. They have begin-*-arity and
end-arity for marking arity information and performing arity prologues.
There are some slight changes to instructions but not much. OTOH they
do have some better type checking and a disassembler that works, so many
things should be easier ;) Compare the rtl.test there and your rtl.test
for details.
* Why is there no let that can bind functions? You don't always
want
to set up a recursive binding environment.
I think right now the Tree-IL-CPS compiler will turn (let ((f (lambda
...))) ...) into something like this:
((lambda (f-12345)
let body here )
(letrec ((f-func (lambda ... f's body here ...))) f-func))
(I'm not showing the continuation's name because it would make it even
more complicated than it already is.)
I agree that this is a crazy way to do it. It should detect this case and
skip the extra steps.
Understood. However the question of language is fundamental for
enabling collaboration on this code. I would be very happy to see a CPS
language definition that could express all of Tree-IL. I don't think
this would take a lot of work -- it is perfectly acceptable to throw
unimplemented for those parts of the compiler that aren't there yet,
but the language itself should be adequately expressive. IMHO anyway.
Do you think you will have time to do that over the next few days or so?
Apologies for the pressure, just that I would like to do some things in
this area and am not sure how best to do them :)
This is interesting - I had been adding to the language as I needed
features, and not really thinking of it as an interface. But you might be
right. I just started rebasing tonight, and I hope to work more on it in
the next two days. But I don't want to be a blocker for your work - what
are you trying to do?
Thanks a lot,
Noah
