[M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Fri Feb 19 07:20:10 CET 2010
HI:
thanks for answering so fast!
Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully.
First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup
more or less it makes you to do
cvsupd -b /diska/cvsup/base/
which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time)
Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned
cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log
This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal:
(First command and executing after it the client with .sup file given there in the web page)
% telnet 192.168.0.3 5999
Trying 192.168.0.3...
Connected to 192.168.0.3.
Escape character is '^]'.
OK 17 0 2009-07-20 14:06:34 CVSup server ready
Connection closed by foreign host.
(After, second command it doesn't wait anything or if some client request, it just finish like this)
% telnet 192.168.0.3 5999
Trying 192.168.0.3...
Connected to 192.168.0.3.
Escape character is '^]'.
Connection closed by foreign host.
% pwd
seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29
(m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server
Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server.
(m3gdb) file LINUXLIBC6/cvsupd
Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(m3gdb) break src/Main.m3:BecomeDaemon
No source file named src/Main.m3.
Make breakpoint pending on future shared library load? (y or [n]) y
Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente.
(m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log
(m3gdb) set follow-fork-mode child
(m3gdb) run
Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log
Signal Stop Print Pass to program Description
SIG64 No No Yes Real-time event 64
[Thread debugging using libthread_db enabled]
[Nuevo LWP 5074]
[Nuevo Thread -1221278032 (LWP 5074)]
In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb.
I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that.
About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform.
Thanks in advance,
--- El jue, 18/2/10, Jay K <jay.krell at cornell.edu> escribió:
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics
> Para: "Daniel (M3)" <dabenavidesd at yahoo.es>, "Olaf" <wagner at elegosoft.com>, "m3devel" <m3devel at elegosoft.com>
> Fecha: jueves, 18 de febrero, 2010 23:54
>
> https://projects.elego.de/cm3/ticket/1080
> can you provide the cvsup configuration file? Thanks.
> Can you try building with user threads and see if it
> occurs?
> Or on another platform?
>
>
> This is definitely something we want to look into.
>
>
> NT386GNU is there and worked for me, but it is slow.
> It had 64bit longint way ahead of NT386, but NT386 is there
> now.
> There is also NT386MINGNU.
>
>
> More testing definitely appreciated.
>
>
> Thanks,
> - Jay
>
>
> ----------------------------------------
> > Date: Fri, 19 Feb 2010 03:07:36 +0000
> > From: dabenavidesd at yahoo.es
> > Subject: Re: [M3devel] More testing needed for m3back,
> was: RE: m3back/longint/atomics
> > To: wagner at elegosoft.com;
> m3devel at elegosoft.com;
> jay.krell at cornell.edu
> >
> > Hi all:
> > great news to hear about a release coming soon, but
> how about testing NT386GNU or derivatives of it, would be
> hard to set up (I might try a friend's machine).
> > As I understood that was a great port to new Modula-3
> programmers coming into the M3 world from win world. This
> doesn't have the all packages but is this a must to give
> have a check to release this port?
> > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080
> ?
> > Is there any chance to bring those platforms in final
> release?
> > Any difficulties to start trying that?
> > Thanks in advance
> >
> > --- El jue, 18/2/10, Jay K escribió:
> >
> >> De: Jay K
> >> Asunto: Re: [M3devel] More testing needed for
> m3back, was: RE: m3back/longint/atomics
> >> Para: "Olaf" , "m3devel"
> >> Fecha: jueves, 18 de febrero, 2010 16:26
> >>
> >>
> >>
> >>
> >>
> >> I added some testing, found/fixed bugs in the gcc
> >> backend (initializing constants, division).
> >>
> >> They should be in the automated tests already.
> >>
> >> However don't let this stop you from doing
> >> everything/anything you can think of.
> >>
> >> I didn't do all that much and you can save time
> and get
> >> more done by not worrying
> >>
> >> about the duplication.
> >>
> >> Pickles I didn't do anything with at all, so if
> you
> >> really want to avoid/delay duplication,
> >>
> >> start with them.
> >>
> >>
> >>
> >> - Jay
> >>
> >>
> >>> Date: Thu, 18 Feb 2010 17:20:56 +0100
> >>> From: wagner at elegosoft.com
> >>> To: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] More testing needed for
> m3back,
> >> was: RE: m3back/longint/atomics
> >>>
> >>> Quoting "Coleburn, Randy"
> >> :
> >>>
> >>>> I can certainly run some tests on
> Windows.
> >>>>
> >>>> I don't have any code that uses longint,
> so
> >> either someone needs to
> >>>> identify which existing programs I can
> build and
> >> run to do the
> >>>> tests, OR I suppose I can write something
> if you
> >> can give me an idea
> >>>> of how extensive the tests you want.
> >>>
> >>> This sounds good!
> >>>
> >>> Some things that come to mind for LONGINT
> >> immeditately:
> >>>
> >>> o standard integer arithmetic (+, -, *, DIV,
> MOD) at
> >> runtime,
> >>> with and without overflows etc.
> >>> o constant declarations
> >>> o constant expressions
> >>> o assignability (should be rather strict; I'd
> have
> >> to check the mail
> >>> archive for the details)
> >>> o pickles
> >>>
> >>> It would be great if you could add some tests
> to
> >> m3tests that are
> >>> valid on all platforms. I expect that some
> should
> >> already be in place,
> >>> but haven't checked yet...
> >>>
> >>> Hm, a quick search for longint in
> >>>
> >>>
> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/
> >>>
> >>> for example doesn't find anything. Has nobody
> >> added any LONGINT
> >>> test yet? Probably I'm looking for the wrong
> >> string...
> >>>
> >>> A complete regression with cm3 and other
> programs you
> >> may have available
> >>> would be great, too, just to make sure that
> the
> >> backend changes
> >>> don't break any old functionality.
> >>>
> >>> Olaf
> >>>
> >>>>
> >>>> I've been trying to keep my system updated
> to
> >> the latest sources on
> >>>> the main trunk, but I've been swamped
> lately
> >> and I'm afraid I'm a
> >>>> few weeks stale right now. I'll remedy
> that
> >> shortly.
> >>>>
> >>>> Regards,
> >>>> Randy
> >>>>
> >>>> ________________________________
> >>>> From: Olaf Wagner [wagner at elegosoft.com]
> >>>> Sent: Thursday, February 18, 2010 6:57 AM
> >>>> To: Jay K
> >>>> Cc: m3devel
> >>>> Subject: [M3devel] More testing needed
> for
> >> m3back, was: RE:
> >>>> m3back/longint/atomics
> >>>>
> >>>> If I understand Jay correctly, it wouldn't
> be
> >> too difficult to bring
> >>>> the m3ack LONGINT changes for Windows into
> the
> >> release branch, but
> >>>> more testing would be needed.
> >>>>
> >>>> Randy, you're the only one I remember
> offhand
> >> who actively uses M3
> >>>> on Windows except for Jay. Could you have
> a
> >> closer look at it?
> >>>> (Changes are only on the trunk right
> now.)
> >>>>
> >>>> Or is anybody else here lurking and eager
> to do
> >> some Windows-based tests?
> >>>>
> >>>> If nobody volunteers, I'm afraid we will
> have
> >> to release without 64bit
> >>>> LONGINT on Windows.
> >>>>
> >>>> Olaf
> >>>>
> >>>> Quoting Jay K :
> >>>>
> >>>>> NT386/longint changes are almost
> entirely in
> >> the m3back package.
> >>>>>
> >>>>> There is also some small easy stuff
> in
> >>>>>
> m3-libs/m3core/src/Csupport/common/hand.c.
> >>>>>
> >>>>> It'd be really great if anyone could
> test
> >> any of this and if
> >>>>> anyone could review the diff between
> release
> >> and head.
> >>>>>
> >>>>> Not just me.
> >>>>>
> >>>>> The changes for longint are quite
> large, even
> >> if local.
> >>>>>
> >>>>> I can port them, in the case of
> m3back, just
> >> copy, and make sure
> >>>>> the atomics stuff doesn't cause
> problems
> >> (it should be unused).
> >>>>>
> >>>>> There is also a small change in
> m3front so
> >> that longint can be initialized.
> >>>>> That affects all platforms.
> >>>>>
> >>>>> And a small change in m3cc/parse.c
> for
> >> div/mod of longint on non-NT386.
> >>>>> I have to test mod yet but my fix
> probably
> >> helps it.
> >>>>>
> >>>>> It'd be really great if anyone could
> do
> >> anything with this stuff.
> >>>>> ie. for now in head, then could easily
> port
> >> to release.
> >>>>>
> >>>>> We can of course release either way,
> >> depending on how satisfied people
> >>>>> are with 32bit longint on NT386. i.e.
> longint
> >> isn't useful portably, but it
> >>>>> is useful on non-NT386 platforms.
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>>> Date: Tue, 16 Feb 2010 16:12:52
> +0100
> >>>>>> From: wagner at elegosoft.com
> >>>>>> To: m3devel at elegosoft.com
> >>>>>> Subject: Re: [M3devel]
> >> m3back/longint/atomics
> >>>>>>
> >>>>>> Quoting Jay K
> >> :
> >>>>>>
> >>>>>>>
> >>>>>>> As far as I know/can
> remember,
> >> longint and atomics should all work
> >>>>>>> now on NT386.
> >>>>>>>
> >>>>>>> Atomics only currently for
> 32bit
> >> types.
> >>>>>>> There are still a few small
> >> inefficiencies to maybe deal with.
> >>>>>>> I'll add 64bit shortly and
> maybe
> >> 8 and 16.
> >>>>>>>
> >>>>>>>
> >>>>>>> We should probably add *a lot*
> more
> >> test coverage in p226 and p227.
> >>>>>>>
> >>>>>>> e.g. longint
> >> multiply/add/sub/divide, not just insert/extract
> like I
> >>>>>>> did a bunch of.
> >>>>>>
> >>>>>> Any volunteers to increase the
> test
> >> coverage?
> >>>>>>
> >>>>>>> Still to fix the Win32
> m3core/libm3
> >> to not always truncate file sizes.
> >>>>>>>
> >>>>>>> Still maybe to do something
> about
> >> rd/wr...?
> >>>>>>>
> >>>>>>> Still to wonder about
> NT386/longint
> >> support in the release branch?
> >>>>>>
> >>>>>> Should we / will you merge this
> stuff to
> >> the release branch?
> >>>>>> Or should we release without it?
> How
> >> local are the changes?
> >>>>>>
> >>>>>> Olaf
> >>>> --
> >>>> Olaf Wagner -- elego Software Solutions
> GmbH
> >>>> Gustav-Meyer-Allee 25 / Gebäude 12,
> 13355
> >> Berlin, Germany
> >>>> phone: +49 30 23 45 86 96 mobile: +49 177
> 2345
> >> 869 fax: +49 30 23 45 86 95
> >>>>
> >> http://www.elegosoft.com |
> >>
> >>>> Geschäftsführer: Olaf Wagner | Sitz:
> Berlin
> >>>> Handelregister: Amtsgericht Charlottenburg
> HRB
> >> 77719 | USt-IdNr: DE163214194
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Olaf Wagner -- elego Software Solutions GmbH
> >>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355
> Berlin,
> >> Germany
> >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345
> 869
> >> fax: +49 30 23 45 86 95
> >>> http://www.elegosoft.com |
> Geschäftsführer: Olaf
> >> Wagner | Sitz: Berlin
> >>> Handelregister: Amtsgericht Charlottenburg HRB
> 77719 |
> >> USt-IdNr: DE163214194
> >>>
> >>
> >>
> >
> >
> >
>
>
>
More information about the M3devel
mailing list