Re: [MiNT] gcc-4.5.0-mint-20100511

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Tuesday 18 May 2010, Vincent Rivière wrote:
> Eero Tamminen wrote:
> > Btw. Did you have time to test whether the multithreaded mudflap
> > support works also?  (one needs to use -fmudflapth for threaded
> > programs)
>
> Does FreeMiNT support multithreading ??

Well, I remember converting one program[1] to use MiNT threads something 
like 14 years ago because MiNT didn't have real fork().  Back then MiNT had
a 4kB limit on thread stacks, currently Linux has 8MB limit for thread
stacks...  But I would assume that MiNT still supports threading. :-)   

[1] a networked game daemon I had done based on the Xpente sources for
the Pente/Renju W & ncurses clients I had written.  The sources are included
with the W window system:
	http://koti.mbnet.fi/tammat/open.shtml#wws


> I have not tried -fmudflapth. This option probably do nothing good.

Yeah, I guess it expects to be running on top of pthread.


> I had noticed that accessing any memory not allocated by the C standard
> functions was considered as a violation, so in a program writing directly
> to the screen I had to do things similar to what you did :
> 	void* p = Logbase();
> #ifdef _MUDFLAP
> 	__mf_register(p, 32000, __MF_TYPE_GUESS, "screen");
> #endif
>
> > export MUDFLAP_OPTIONS="-viol-gdb -internal-checking -wipe-stack
> > -wipe-heap"
>
> I didn't try the MUDFLAP_OPTIONS variable, but it should work.
>
> > Btw. Vincent, does GDB invocation from Mudflap code work?
>
> Do you mean GDB running mudflap programs ?
> Or some GDB invocation from inside the mudflap programs ?

Mudflap being able to invoke Gdb whenever it notices some problem.
It was quite handy with Hatari.


> I have no idea.
>
> I forgot to say it was the first experimental build of libmudflap for
> MiNT, the basic features work, but I have no idea about advanced
> features. I had never used libmudflap before that.

To test the Gdb invocation, just run a program compiled with mudflap
and triggering some mudflap warning like this:
	MUDFLAP_OPTIONS="-viol-gdb" ./program


> Eero, since you seem experimented, feel free to test libmudflap for MiNT
> and tell us what works or not ! Then we will fix things progressively.

I haven't had a working MiNT / Atari unix setup for almost 10 years. I've
been intending to set up something up for last few years, but Hatari has
been eating all my "Atari time".

MiNT can be run under Hatari, but because MiNT replaces GEMDOS functions
with its own, it doesn't work with Hatari GEMDOS based harddisk directory
emulation, only with harddisk images.

The soon to be released Hatari v1.4 has had quite a lot of fixes to harddisk
driver related issues (Uwe Seimet debugged some IDE issues Hatari had with
HD driver, thanks!), so now it's possible to use both GEMDOS emulation and
harddisk emulation at the same time to copy files between the host and
emulated system (when not running MiNT).

Another related issue are the VFAT support issues in (Emu)TOS, which
prevents reliable copying of data between GEMDOS HD emulation and HD disk
image drives.

These have been an issue in setting up a nice MiNT environment.  Hatari
doesn't support Aranym NatFeats which with the related MiNT drivers would
allow sharing things with the host also when running MiNT.


Btw. Does somebody have a non-NatFeats-requiring fVDI setup & latest
binaries I could test with Hatari?



	- Eero

PS. In case this sounded like Hatari bashing, Hatari aims at exceling on 
emulating the real HW instead of offering shortcuts to the host.  Former is
important when trying to get demos & games working, latter when running well
behaving GEM apps. I'm inclined towards former (as I use Linux for unix
stuff), so I use Hatari instead of Aranym...  It would still be nice to get
good MiNT setup under Hatari too, but it's been less of a priority for me.