gmane.os.minix.ack

Re: linux68k emulation

David Given — 2013-05-18T12:08:38

[...]

*facepalm* Yes, absolutely right. Fixed and pushed (and it sets errno
now). Sorry about that.

linux386 binaries now run up to a point, but fall over when they try to
read from stdin (somewhere inside
lang/cem/libcc.ansi/stdio/fillbuf.c:__fillbuf). This seems vaguely
familiar; I'll try to look into it later.

The linux68k binaries still don't run under qemu, though --- it seems
that stock qemu only supports ColdFire processors, and the ACK is
generating non-ColdFire instructions.

Re: Build system replacement

David Given — 2013-05-18T11:50:44

I am not even slightly surprised! Thank-you very much for that. It's
committed and pushed.

[...]

I'm curious as to why this didn't show up on my Linux 64-bit machine,
though. I don't think the ABIs are different between Linux and OpenBSD.

I've just tried compiling (with the incorrect code) with
-Werror=int-to-pointer-cast, as this is obviously something we need to
be aware of, but while the warning still appears it's not upgraded to an
error. Very odd.


For doing incremental builds, you might want to try adding -r. This will
prevent make from looking for CVS, RCS, ~v etc files, and can shave
several seconds of startup. If you're only building one thing this can
be quite a high proportion of the total.

Re: linux68k emulation

George Koehler — 2013-05-18T02:45:33

This is a regression.  I built working linux386 programs at April 24 or 
25, probably with revision 0771f59.

Looks like sbrk() is broken.  I don't have gdb for Linux/m68k, but I do 
have gdb for FreeBSD/i386.  This gdb can run Linux program.  So I ran 
paranoia and got $pc of crash.

I made a symbol table with
$ ack -mlinux386 -c.out -O paranoia.c
$ anm paranoia.out | sort | less

This locates crash in create_chunk() from 
lang/cem/libcc.ansi/stdlib/malloc/phys.c.  This function initializes 
memory from sbrk(), so I suspect that sbrk() is broken.

Current plat/linux/liblinux/sbrk.c is not same as 0771f59 
plat/linux386/libsys/sbrk.c, and they can't both be correct.  Did 
liblinux forget a bug fix?

After reading [1], I believe that _syscall(__NR_brk, addr, 0, 0)
* tries to set break to addr.
* returns addr on success, or current break on failure.
* never sets errno.

So I guess that current sbrk() is wrong, 0771f59 sbrk() was about 
correct but never sets errno, and brk() was always wrong.  I suspect 
that

Re: Build system replacement

George Koehler — 2013-05-17T22:15:59

This broke the build for OpenBSD/amd64.

Please commit the fixes in the attached patch (fix-build.diff).

First, cd $(dir $o) fails if $o is more than one file.  The builtin cd 
of OpenBSD /bin/sh is too dumb to know that they are all in the same 
directory:

$ cd /tmp /tmp
sh: cd: bad substitution
$ cd /tmp /tmp /tmp
sh: cd: too many arguments

Second, commit 7f0b1e3 removed #include "idf.h" from too many files in 
lang/cem/cemcom.ansi.  So em_cemcom.ansi dumped core.  Then gdb found no 
debugging symbols in em_cemcom.ansi, so the backtrace was useless; but I 
inserted warnx() calls into cemcom.ansi until I located the problem.  It 
was this line in options.c:

         macro_def(str2idf(name, 0), mactext, -1, (int)maclen, NOFLAG);

Since options.c no longer included idf.h, it no longer declared the 
return type of str2idf().  So gcc assumed that str2idf() returned an 
int.  This truncated a 64-bit pointer into a 32-bit int.  Then 
macro_def() dereferenced the bad pointer and dumped core.

The new build sys

Re: Build system replacement

Rogelio Serrano — 2013-05-17T14:34:09

Its the limitation of make. im actually writing a make replacement to
handle that...

Re: Build system replacement

David Given — 2013-05-17T14:25:46

[...]

Unfortunately the highly dynamic nature of the ACK --- which builds
program which create files which are then used to build other programs
which generate source code which is then finally compiled *several
times* into the end result --- tends to make build systems curl up in a
corner and cry. I've yet to find a build system that could cope with
this sort of thing in a sane manner (and would love to find one, I do a
lot of this stuff at work).

The new build system more-or-less generates makefiles on-the-fly using
loathsome make macros. It's really not pretty. Go take a look at the
build.mk files some time...

Re: Build system replacement

Rogelio Serrano — 2013-05-17T13:54:25

8 cores! wow! im jealous!

on the other hand thats a very welcome change because i have been thinking
about this for a while already. just a bunch of simple non recursive
makefiles


On Fri, May 17, 2013 at 9:10 PM, Godzil <godzil< at >godzil.net> wrote:

Re: Build system replacement

Godzil — 2013-05-17T13:10:15

Irronically, I was thinking about replacing pm with cmake on my fork :D

On 17/05/13 11:52, David Given wrote:



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: linux68k emulation

David Given — 2013-05-17T10:02:20

I've actually recently done a whole bunch of work on the ACK's build
system --- see my other email for details. I also found and fixed a
genuine ACK core bug:

http://tack.hg.sourceforge.net/hgweb/tack/tack/rev/8dad11dd055b

So you may want to update, if you haven't already.

[...]

I do remember that when I originally did the linux68k port, I was
testing with qemu-m68k (which will run 68k binaries directly in a user
process). Trying it now, I see exactly the same results you do --- stdio
stuff fails, non-stdio stuff works. (examples/mandelbrot.c doesn't use
stdio.)

linux386 behaves identically. So I suspect that this is a libc issue
rather than a compiler issue.

Build system replacement

David Given — 2013-05-17T09:52:31

I've just done a whole bunch of work on the ACK, replacing the build
system. I've ripped Prime Mover out and replaced it with a set of scary
makefiles. It's now fully parallelisable and has better dependency tracking.

Prime Mover worked very nicely, and was a big improvement over the
previous piles-of-recursive-makefiles-and-scripts, but now that I own a
multicore machine it's amazing how much more important parallelisation
became...

On this 8-core machine I can now do a full ACK rebuild in 8 seconds.

Instructions are in the README. I've left all the pmfiles in for
reference, but removed the root ./pm script as it doesn't work any more.

...I've also fixed a bunch of warnings and gotten the Basic compiler to
work again. This last may be useful to someone.

linux68k emulation

George Koehler — 2013-05-17T03:18:40

Now that ack has linux68k, has anyone tried running its executables? I 
played inside Aranym, the 68k emulator.

I compiled a few programs,
$ ack -mlinux68k -O hilo.mod -o hilo
$ ack -mlinux68k -O paranoia.c -o paranoia
$ ack -mlinux68k -Dssize_t=int -O yousaid.c -o yousaid

I took hilo.mod and paranoia.c from ack/examples, and attached yousaid.c 
to this email.

./hilo and ./paranoia both cause Segmentation fault. ./hilo faults after 
1 second, ./paranoia faults immediately. I know not cause of segfault.

./yousaid works perfectly. It is a small program to test read() and 
write() with the console, and never calls other functions like printf().
--George


Aranym <http://aranym.org/> emulates an Atari with a 68040. It seems the 
only 68k emulator with an MMU. I believe that I need MMU to run Linux or 
NetBSD.

linux68k is almost a dead platform. Its last distro, Debian, has no 
regular installer, but does provide a convenient enough Aranym disk 
image. I built my own Aranym with --enable-mmu --enable-lilo, b

Re: arm and powerpc assembly

David Given — 2013-05-10T11:13:21

[...]

I've merged all this into trunk (except the stack offset changes in the
code generator). linux68k is enabled by default.

linuxppc is *not* enabled by default. It turns out that when compiling
the code generator table for PowerPC, ncgg repeatedly errors out with:

    Previous rule impossible on empty stack

One of the rules that's causing this is as follows:

        pat adf $1==INT32                  /* Add single */
                with FS FS
                        uses reusing %1, FREG
                        gen
                                fadds {FS, %a}, %2, %1
                        yields {FS, %a}

(The full file is here:
http://tack.hg.sourceforge.net/hgweb/tack/tack/file/4fe6836f55cb/mach/powerpc/ncg/table)

It would seem that back when I was doing all this, I managed to work
around the error by simply commenting out the code that makes the error
in ncgg!

I don't actually know what the error means. I assume it's something to
do with the contents of the fake stack. But I don't know why

Re: arm and powerpc assembly

David Given — 2013-05-09T14:57:23

[...]

That's working now.

The code's much less bad than I thought. The biggest problem is that it
insists on passing parameters on the stack --- I'm not sure if there's a
way round this; I suspect this is required by the em spec --- but the
code quality is otherwise perfectly serviceable. The behaviour I
remembered where floating point values would be loaded by shuffling them
via integer registers doesn't seem to be showing up, either. (OTOH
there's no floating point register variable support, so float code
continually hits memory. That could be relatively easily fixed, should
anyone wish.)

I'd also modified aelflod to generate non-386 ELF files, but George
Koehler's patch was better than mine so I've replaced it with his. The
linux386, linuxppc and linux68k platforms all now generate executables.

I should point out that I haven't actually tried *running* them...

Re: arm and powerpc assembly

David Given — 2013-05-08T08:31:25

[...]

...which seems to be missing at least two important directories. (Never
check things in after midnight.) I should be able to fix that tomorrow.

Re: arm and powerpc assembly

David Given — 2013-05-08T00:04:51

[...]

So that's all checked in now... and there was a lot more stuff there
than I expected.

The PowerPC code generator all builds and runs, although I don't know
whether it generates working code; the code quality is pretty dire but
much less bad than I remember. There's a linuxppc plat to put it all
together but trying to build executables fails.

There is *also* a linux68k plat which uses the m68020 code generator.
That's checked in too (and produces quite nice code; the m68k's
addressing modes play nicely with em). As there's now three Linux plat,
I also seem to have factored out a lot of the platform-independent Linux
runtime code into plat/linux.

In addition I found why I never checked all this in. I'd added EM
support for a new opcode, STACKADJUST. This was used to tell ncgg about
changes to (sp-fp), to allow it to calculate fp on-the-fly and not have
to store it in a register.

I recall that all this *worked*... for C. Unfortunately it violated some
core em assumptions which caused the other langua

Re: arm and powerpc assembly

David Given — 2013-05-06T17:14:44

The PowerPC support was written by me, years ago, in a tearing hurry and
is rather unfinished. Oddly enough I actually had reason to look at it
again a few days ago (I find myself needing a quick-and-dirty C compiler
and tool chain for the Videocore IV, and was wondering whether the ACK
would be a good choice).

I didn't realise until then it was so broken! Sorry about that. I seem
to have forgotten to check in a lot of the files. Strangely enough, my
working directory from when in did the work in 2007 still exists...


Looking at the code brings back a few memories --- in order to support
the high-word relocations needed by the PowerPC I had to add a new
relocation type, but only checked in the assembler side of things. I
have no idea why not. There are changes needed elsewhere too. I have
actually found these in the working directory and will try to check them
in soon.

[...]

The < and > syntax seems to be mine; I don't know where I got it from.
It might be possible to copy the GNU syntax. You're right a

arm and powerpc assembly

George Koehler — 2013-05-04T03:44:58

Today, there is no platform for mach/powerpc.  I try a platform for 
PowerPC test machine in GXemul (http://gxemul.sourceforge.net/), just 
because running GXemul is easier than turning on my old PowerPC 
Macintosh.  I also try ARM.

The attached patch shows my progress so far.  I created platforms 
'gxarm' and 'gxppc'.  These can only assemble .s files.  The assemblers 
are broken enough that I have not yet built ncg for .e files.

The patch includes some example programs that write to GXemul console.  
They use the GXemul devices documented at
     http://gxemul.sourceforge.net/gxemul-stable/doc/experiments.html

I can't build the PowerPC assembler as is.  It needs flags RELOH2 and 
RELOPPC and function fitx(), but those don't exist.  For now I kludge 
around this.

To put address of string in %r4, GNU syntax might be
     lis %r4, string< at >ha
     addi %r4, %r4, string< at >l

ACK doesn't have convenience mnemonics like 'lis'.  One must use 
'addis'.  Also, ACK can't do '< at >ha' (High Adjusted; string< at >l might be 
n

Re: aelflod pull request

David Given — 2013-05-03T11:25:52

That's done (I hope); thank-you very much. Sorry about the delay.

aelflod pull request

George Koehler — 2013-04-26T14:42:23

Please pull 0771f59 from
https://bitbucket.org/kernigh/ack-fix

Some fixes for aelflod and aslod.

Copy rhead() and rsect() from aslod to aelflod, so aelflod can work
for machine with 64-bit long.

In aelflod, fix ELF header so file(1) no longer reports "corrupted
section header size".

----
Until now, ack -mlinux386 ... would usually fail with an error, like 
"segment must follow" something. Now I can build linux386 programs. I 
run ack from OpenBSD/amd64, which does have 64-bit long.

I had to test the linux386 programs somehow. For some reason, I can 
never boot Linux inside Bochs or QEMU (the two emulators with OpenBSD 
packages). But I can boot BSD there, and FreeBSD has Linux 
compatibility, so I installed FreeBSD/i386 in QEMU and tested linux386 
programs there.
--George Koehler

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powe

Re: New comer on ACK

Rogelio Serrano — 2013-04-11T12:26:56

can we add annotated pointer types to EM?


On Thu, Apr 11, 2013 at 5:33 PM, Ceriel Jacobs <c.j.h.jacobs< at >vu.nl> wrote:

Re: New comer on ACK

Ceriel Jacobs — 2013-04-11T09:33:35

Not much light to shed, I'm afraid. David is right, EM does not support
annotated pointer types.

Best wishes,

Ceriel Jacobs


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter