basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Re: MacOS X port of Basilisk II

[Christian B. <cb...@st...>]

Hi!

On Fri, Jun 29, 2001 at 07:10:49PM +1000, ni...@in... wrote:
> The only ones I would like to keep as PD are NNThread.h & m, as I have
> already e-mailed versions of these to developers on the macosx-dev mailing
> list.

As the author of a program, you are of course free to issue different licences
to different people.

> 2) As a general observation, most of Balisisk II's source code _is_
>    actually C. (i.e. there are no classes, overloaded operators, et c.)

As a general warning, however, I intend to use more C++ in the future,
where appropriate (one thing I'm planning is to rewrite the prefs module
to use a map<>).

> 	What if I produce a parody of the happy face, like a wrinkled
> old version thereof?

B2 is not a wrinkled version of anything! ;-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Re: MacOS X port of Basilisk II

[<gb...@di...>]

Hi,

>       Is there some version of a license which _is_ compatible
> with GPL, but doesn't prevent prople from doing whatever they damn
> well please with the source files?

I don't know, I will try to dig more info on the GNU site.

> > 2. Mixing C++ and Objective-C is not quite possible at the current time=
.
> > Therefore, Nigel implemented a few C wrappers. However, I think we don'=
t
> > need them if we declare functions in src/include/*.h with "C" external
> > linkage. If this approach works, I will remove Nigel's C wrappers and
> > commit patched versions of includes with various #ifndef __cplusplus__ =
/
> > extern "C" clauses.
>=20
> 1) I think that will just cause link errors, as the files would have been
>    compiled one way (as C++ interfaces, because they are in .cpp files),
>    but referenced as another. (C interfaces in my Objective-C source)

No, they will have "C" linkage because they would have been declared as
such (extern "C").

> 2) As a general observation, most of Balisisk II's source code _is_
>    actually C. (i.e. there are no classes, overloaded operators, et c.)

There are classes for serial emulation for example (in os-specific parts
however) and some bits of STL now. In my experiments with Reversed
Address Space, I do use operator overloading as well (that's not in CVS
though).

>       I haven't looked at that site yet, but it could potentially be
> a problem, as could some of the structures I typed into extfs_MacOSX.cpp

OK if that's a problem, I will keep the "unix" version if it works. I
haven't tried it yet with my Darwin/X11 port.

>       What if I produce a parody of the happy face, like a wrinkled
> old version thereof?

I don't know. Christian said some time ago that someone was to
contribute a nice icon but nothing appeared since. I think there are
artists as B2 users, they would probably be pleased to contribute one if
we ask them ? ;-)

Bye,
Gwenol=E9.

[B2-devel] Re: MacOS X port of Basilisk II

[<ni...@in...>]

Gwenole asked:
>
> 1. License. Currently Nigel placed his code into Public Domain. I don't
> think it is compatible with GPL. I will add the usual GPL header and add
> Nigel's name in all sources he sent me. I need suggestions/agreements
> here.

	I only labelled some of my code as public domain.
Here are the ones that did not include a standard B2 GPL header:

File               Currently  Comments
----------------------------------------------------------------
cpp_glue_MacOSX.h     PD      Fix it
main_MacOSX.h & m     PD      Partially derived from Apple junk?
video_MacOSX.h        PD      Fix it
Controller.h & m     None     Fix it
Emulator.h & m       None     Fix it
EmulatorView.h & m   None     Fix it
NNThread.h & m        PD      Not B2 specific, already released
PrefsEditor.h & m    None     Fix it
================================================================

For most of the files, it doesn't matter. The only ones I would
like to keep as PD are NNThread.h & m, as I have already e-mailed
versions of these to developers on the macosx-dev mailing list.

	Is there some version of a license which _is_ compatible
with GPL, but doesn't prevent prople from doing whatever they damn
well please with the source files?


(Probably not. I can't have it both ways.
 If necessary, I can e-mail those developers and tell them
 that from version 3 onwards those files are under GPL)




> 2. Mixing C++ and Objective-C is not quite possible at the current time.
> Therefore, Nigel implemented a few C wrappers. However, I think we don't
> need them if we declare functions in src/include/*.h with "C" external
> linkage. If this approach works, I will remove Nigel's C wrappers and
> commit patched versions of includes with various #ifndef __cplusplus__ /
> extern "C" clauses.

1) I think that will just cause link errors, as the files would have been
   compiled one way (as C++ interfaces, because they are in .cpp files),
   but referenced as another. (C interfaces in my Objective-C source)

   For this to work, all the B2 source would probably have to be moved
   into .c files

2) As a general observation, most of Balisisk II's source code _is_
   actually C. (i.e. there are no classes, overloaded operators, et c.)

   If, in the future, the code is going to start passing objects around,
   then keeping it the way it is, and for OS X to use wrappers, is the
   only way to go.


> 3. Naming conventions. File names currently have the form
> extfs_MacOSX.<extension>. I'd prefer to lowercase them in order to be
> consistent with the other ports.

	Doesn't matter to me.


...
> 5. Icon. Though it looks really good, I don't think we can include it
> because the background logo is the MacOS happy face.
> <http://www.apple.com/legal/>

	I haven't looked at that site yet, but it could potentially be
a problem, as could some of the structures I typed into extfs_MacOSX.cpp

	For the icon, maybe the makefile could generate it on the fly
from the happy face in the installed OS? Would still be a problem for
distributing a precompiled binary though.

	What if I produce a parody of the happy face, like a wrinkled
old version thereof?


> 6. Delays. I have a very busy week right now. So I am not sure if I
> could patch/upload everything before next week.

	No hurry.

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] Re: [Basilisk-cvs] BasiliskII/src/Unix video_x.cpp

[Christian B. <cb...@st...>]

Hi!

On Thu, Jun 28, 2001 at 12:44:38AM +0200, Gwenole Beauchesne wrote:
> That's nice, 0.9.1 is showing up ? ;-)

Rather 1.0 :-)

> - What are we supposed to return when we can't change resolution/depth
> (memory re-allocation error, failure in DGA vidmode switching, etc.) ?

You are supposed to crash. :-)

The MacOS Display Manager was obviously designed for interfacing with
video _hardware_ and it assumes that when a mode is supported, it can be
switched to. Since no return value is being checked, there is no point
in providing one.

> - In direct addressing, we used to determine the base address of the Mac
> framebuffer from the host address. Does your infrastructure permit
> dynamic relocation of the Mac frame buffer ?

Yes, this should work.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Re: [Basilisk-cvs] BasiliskII/src/Unix video_x.cpp

[<gb...@di...>]

Hi,

> depth/resolution switching infrastructure should be complete now; slot RO=
M
> contains all supported depths, default mode is stored in XPRAM upon start=
up,
> and added video_switch_to_mode() call (currently unimplemented in all dri=
vers)

That's nice, 0.9.1 is showing up ? ;-)

- What are we supposed to return when we can't change resolution/depth
(memory re-allocation error, failure in DGA vidmode switching, etc.) ?

- In direct addressing, we used to determine the base address of the Mac
framebuffer from the host address. Does your infrastructure permit
dynamic relocation of the Mac frame buffer ?

The latter problem can arise when we need to reallocate the frame buffer
to fit the new video mode. However, this can be easily fixed by
pre-allocating memory for the highest host video mode configuration, at
least for the_buffer[]. That will work but that's not really clean even
if only pages that are actually used reside in physical memory.

Bye,
Gwenol=E9.

Re: [B2-devel] MacOS X port of Basilisk II

[<gb...@di...>]

> 4. Project Builder. Currently, building the MacOS X port requires the
> use of Apple's IDE. It would be better to workaround that. i.e. just
> typing ./configure (generated) ; make should work.

Hmm, reading the Project Builder FAQ, "pbxbuild" seems to be the
solution. However, I will try to investigate more in order to get
cpuemu.cpp compilation time reduced to a minimum.

Bye,
Gwenol=E9.

[B2-devel] MacOS X port of Basilisk II

[<gb...@di...>]

Hi,

Thanks to Nigel, I could get the tarballs for the MacOS X port of
Basilisk II. Before committing it to CVS, I have a few comments and
suggestions to make.

1. License. Currently Nigel placed his code into Public Domain. I don't
think it is compatible with GPL. I will add the usual GPL header and add
Nigel's name in all sources he sent me. I need suggestions/agreements
here.

2. Mixing C++ and Objective-C is not quite possible at the current time.
Therefore, Nigel implemented a few C wrappers. However, I think we don't
need them if we declare functions in src/include/*.h with "C" external
linkage. If this approach works, I will remove Nigel's C wrappers and
commit patched versions of includes with various #ifndef __cplusplus__ /
extern "C" clauses.

3. Naming conventions. File names currently have the form
extfs_MacOSX.<extension>. I'd prefer to lowercase them in order to be
consistent with the other ports.

4. Project Builder. Currently, building the MacOS X port requires the
use of Apple's IDE. It would be better to workaround that. i.e. just
typing ./configure (generated) ; make should work.

5. Icon. Though it looks really good, I don't think we can include it
because the background logo is the MacOS happy face.
<http://www.apple.com/legal/>

6. Delays. I have a very busy week right now. So I am not sure if I
could patch/upload everything before next week.

Thanks,
Gwenol=E9.

Re: [B2-devel] Re: Direct Addressing and Darwin/MacOS X

[Christian B. <cb...@st...>]

Hi!

On Fri, Jun 22, 2001 at 10:23:01AM +0200, Gwenole Beauchesne wrote:
> before crashing in supposedly select(), ... on a branch instruction!?

Maybe some kind of load delay is in effect here?

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Direct Addressing and Darwin/MacOS X

[Christian B. <cb...@st...>]

Hi!

On Thu, Jun 21, 2001 at 08:12:27AM +0200, Gwenole Beauchesne wrote:
> Is it OK for the following functions going into src/Unix/vm_map.cpp ?

Just do it.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Re: Darwin/MacOS X

[<gb...@di...>]

Hi,

>       I do not have commit (nor the ability to use CVS through my
> work's very restrictive firewall), so someone else will have to put
> it in there.

I think you should see administravia (e.g. add your SourceForge username
to the list of B2 developers, CVS account, etc.) with Christian since he
is the project leader/manager.

>       Shall I mail you some tarball(s) ?

That's only an extra MacOSX sub-directory, isn't it ? If the taballs are
not too big (< 5 MB), you can send them to me at <gb...@di...>.
You can put the tarballs on some website if you wish (simpler if others
want to have a look at it too).

I can commit it for you, if this is OK for other developers.

Thanks,
Gwenol=E9.

[B2-devel] Re: Darwin/MacOS X

[<ni...@in...>]

> >       Won't be a problem, as my MacOS X port currently doesn't use
> > main_unix.cpp anyway. (most of its stuff is in cpp_glue_MacOSX.cpp)
> 
> OK. BTW, is it advanced enough now so that it could be integrated
> into CVS ?

	Yes. I think so. Window resizing, and (I think) all of the
preferences editing stuff now works. The extfs stuff will definately
be of use to you (assuming you haven't already implemented it).


	I do not have commit (nor the ability to use CVS through my
work's very restrictive firewall), so someone else will have to put
it in there.

	Shall I mail you some tarball(s) ?

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] Re: Direct Addressing and Darwin/MacOS X

[<gb...@di...>]

Hi,

> 2) Sounds like you have had more success than I.
>    I wasn't able to use _any_ mmap() calls under OS X.
>    (it always gives an errno that says the function is unimplemented)

Indeed, mmap() does not work when you specify a file to map from.
Instead, simply add MAP_ANON to the list of flags and set the file
descriptor to -1.

> 3) You may want to investigate the map_fd(), vm_allocate() and
>    vm_deallocate() calls in this old Rhapsody (NextStep) document:

Thanks, I have just added those system calls. Unfortunately, B2 still
crash in some select() in either implementation (vm_allocate() or
mmap()). I thought it may be due to the select() call in Delay_usec()
but turning the select() to an usleep() still makes B2 to crash.

Actually, as I supposed earlier, the crashing behavior appears when VOSF
is enabled (use_vosf =3D true in video_x.cpp). That may be due to some
combination of signal/sigsegv handler/vm_protect/...

VideoRefresh() didn't have a chance to get called. Instead, the screen
remains black and logging shows me that only a few pages get unprotected
before crashing in supposedly select(), ... on a branch instruction!?

As a temporary workaround, I think i will disable VOSF in Darwin but
still do direct addressing. That works and provides an interesting
speedup (15-25%).

> > Note: vm_protect() exists in Mach/Darwin environments but with 4
> > arguments. This is not a problem since we use C++. Could this be a
> > problem for Objective C if Nigel wants to have the same naming
> > conventions ?
>=20
>       Won't be a problem, as my MacOS X port currently doesn't use
> main_unix.cpp anyway. (most of its stuff is in cpp_glue_MacOSX.cpp)

OK. BTW, is it advanced enough now so that it could be integrated into
CVS ?

Bye;
Gwenol=E9.

[B2-devel] Re: Direct Addressing and Darwin/MacOS X

[<ni...@in...>]

...
> Having said that, I have just realized Darwin doesn't honor the
> protection flags passed to mmap() (say PROT_READ only). So, an explicit
> mprotect() has to be done just after that. I am going to wrap a number
> of mmap()/mprotect() functions to reflect that and also the fact that
> Darwin doesn't support mapping memory from device files (MAP_ANON works
> though).

1) Wrappers? Good idea.

2) Sounds like you have had more success than I.
   I wasn't able to use _any_ mmap() calls under OS X.
   (it always gives an errno that says the function is unimplemented)

3) You may want to investigate the map_fd(), vm_allocate() and
   vm_deallocate() calls in this old Rhapsody (NextStep) document:

   http://developer.apple.com/techpubs/macosx/Legacy/Mach.pdf

   (Take a copy of it. It may disappear)


...
> Note: vm_protect() exists in Mach/Darwin environments but with 4
> arguments. This is not a problem since we use C++. Could this be a
> problem for Objective C if Nigel wants to have the same naming
> conventions ?

	Won't be a problem, as my MacOS X port currently doesn't use
main_unix.cpp anyway. (most of its stuff is in cpp_glue_MacOSX.cpp)

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

[B2-devel] MacOS X & VOSF & segfaults in select()

[<gb...@di...>]

Hi,

I finally implemented vm_* functions thus causing configure test
programs to pass and enabling VOSF. Everything compiles correctly. The
problem is that after a few hits to the sigsegv handler (and probably
VideoRefresh()), I get some null pointer deferencing for IP = 0x700118.
Disassembling that portion of code with gdb leads to select().

I have no other clue so far. We can live without VOSF under MacOS X but
still do direct addressing because that's the same endianess and the
same RGB mask values between native and emulated environments. However,
that's a special case and I would find changing the configure script to
reflect that is simply dirty.

I wonder if I'd better use Mach vm_allocate/vm_deallocate/vm_protect
functions instead of trusting mmap() and the like...

[B2-devel] Direct Addressing and Darwin/MacOS X

[<gb...@di...>]

Hi,

I made some arrangements to sigsegv.cpp in order to support Darwin in
VOSF / direct addressing. The sole problem so far is that the usual
hacks for retrieving the fault address don't work there. Instead, we
currently need to decode the faultive instruction and read the address
from the saved register set. This hack comes from Boehm's garbage
collector 6.0alpha8 that comes from some other contributor.

Having said that, I have just realized Darwin doesn't honor the
protection flags passed to mmap() (say PROT_READ only). So, an explicit
mprotect() has to be done just after that. I am going to wrap a number
of mmap()/mprotect() functions to reflect that and also the fact that
Darwin doesn't support mapping memory from device files (MAP_ANON works
though).

Is it OK for the following functions going into src/Unix/vm_map.cpp ?
- address =3D vm_acquire(size)
- address =3D vm_acquire_fixed(address, size)
- void vm_release(address, size)
- rc =3D vm_protect(address, size, prot_flags) where prot_flags are:
  VM_PAGE_READ / VM_PAGE_WRITE / VM_PAGE_EXEC

This should also simplify some code in main_unix.cpp.

Note: vm_protect() exists in Mach/Darwin environments but with 4
arguments. This is not a problem since we use C++. Could this be a
problem for Objective C if Nigel wants to have the same naming
conventions ?

Bye,
Gwenol=E9.

Re: [B2-devel] Re: config problems

[<gb...@di...>]

> I will commit a new configure script into CVS as a temporary workaround.

Ooops, I forgot that configure is not in CVS :-/

Re: [B2-devel] Re: config problems

[<gb...@di...>]

Hi,

>       I could be wrong here, or misunderstanding the problem, but
> if the program that autoconf and ./configure is generating will not
> compile, then doesn't that mean that the version of autoconf, or its
> data files, is incompatible with the SGI?

Some linux distributions come with an autoconf package that patch some
m4 macros in order to add a declaration for exit(). Unfortunately, that
declaration is wrong pedantically speaking but provide a hint for GCC to
optimize code in C++ (see. <sys/cdefs.h> in glibc 2.2.x).

I will commit a new configure script into CVS as a temporary workaround.

>       The fix may be as simple as installing a later version of
> the autoconf package.

OK, check CVS (grabbed from gcc-3.0). BTW, though autoconf 2.50 works
well with Basilisk II, it is an exception because it seems that so many
packages out there aren't really compatible with that new version of
autoconf.

Bye,
Gwenol=E9.

[B2-devel] Re: config problems

[<ni...@in...>]

	On Mac OS X, the configure script generated by autoconf did
not work because it did not know about that version of Unix. What I
had to do was replace the config.guess and config.sub files in the
Unix directory with the versions from /usr/libexec

	I could be wrong here, or misunderstanding the problem, but
if the program that autoconf and ./configure is generating will not
compile, then doesn't that mean that the version of autoconf, or its
data files, is incompatible with the SGI?

	The fix may be as simple as installing a later version of
the autoconf package.

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] config problems

[Brian J. <bjj...@us...>]

On Tue, 5 Jun 2001, Christian Bauer wrote:
> > On Tue, Jun 05, 2001 at 06:18:55AM +0200, Gwenole Beauchesne wrote:
> > > I think we have to come up with a subterfuge to fool the
> > > compiler's data flow analyzer.
> >
> > "volatile"?
> 
> Yes but according to Brian that doesn't seem to do the trick though
> it should unless there is a bug in SGI C++ compiler ?

Declaring page[] as "volatile" keeps the compiler from removing the
second write, but that's all that "volatile" is required to do.  It
doesn't enforce any sort of ordering between page[] and
handler_called.  You need some sort of explicit dependency or
something the compiler can't move (like a system call) for that.  From
what I'm told, gcc loads a lot more meaning onto "volatile" than the
spec really requires.

BTW, I didn't have any trouble with the sigcontext subterfuge tests,
but perhaps I just got lucky.  IRIX doesn't require a subterfuge.

> > > On Tue, Jun 05, 2001 at 06:18:55AM +0200, Gwenole Beauchesne wrote:
> > > I think we have to come up with a subterfuge to fool the
> > > compiler's data flow analyzer. Something like a fake use after
> > > each write.

But that still wouldn't do the trick, would it?  "volatile" will
ensure that two writes are generated, but we still need a way to make
sure the handler_called is read after the writes.

There's a __synchronize() compiler intrinsic which explicitly enforces
this restriction.  That's probably the safest way to go, at least for
SGI's compilers:

***************
*** 281,286 ****
--- 281,290 ----
        page[123] = 45;
        page[123] = 45;
  
+ #ifdef sgi
+       // Keep SGI's MIPSPro compilers from moving the read of handler_called
+       __synchronize();
+ #endif
        if (handler_called != 1)
                return 1;

Looking at the generated code, it seems to do exactly the right
thing.

> > > Brian, is your compiler still optimizing enough to inline a
> > > function defined after its call is issued ? Let's have for
> > > example:
> > > ...
> > > int main() {
> > >   int some_int;
> > >   foo(&some_int);
> > > }
> > > 
> > > void foo(int *) {
> > >   printf("foo\n");
> > > }

Yes.  It completely removes foo(), and main() degenerates into a
simple call to printf().  9 MIPS instructions, counting the stack
frame setup and teardown, and the implied return(0).

(When you select a high enough optimization level, SGI's compilers
actually compile into an intermidiate code, and let the linker invoke
a full interprocedural analysis before code generation even begins.
So the interprocedural optimizer always has complete information.  It
takes a _long_ time to link an application as huge as BII, but the
resulting code is worth it.)

						Brian

--------------------------------------------------------------------

  "I use not only the brains I have, but all I can borrow."
                                           -- Woodrow Wilson

Re: [B2-devel] Plan for 0.9 release ?

[Christian B. <cb...@st...>]

Hi!

On Sun, Jun 03, 2001 at 01:40:39PM +0200, Gwenole Beauchesne wrote:
> Ouch, I will then have to bug hunt why, in double-precision, MacOS 8
> scrollbars don't scroll whereas the window contents do scroll. In
> extended-precision, the scrollbars behavior is as expected.

MacOS 8 does Int->FP conversion by constructing an 80-bit float in memory
with a fixed exponent and writing the value into the lower (upper?) part
of the mantissa. This FP number is unnormalized. When a 68k FPU loads such
a number, it gets normalized. When an x86 FPU loads it, it generates an
error. That's the "scrollbar bug".

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] B2+DGA=OK

[Christian B. <cb...@st...>]

Hi!

On Sun, Jun 03, 2001 at 01:40:41PM +0200, Gwenole Beauchesne wrote:
> Do you accomplish the same for /dev/mem (XF86 DGA) ?

This only used to work for old versions of XF86...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] config problems

[Gwenole B. <gb...@di...>]

On Tue, 5 Jun 2001, Christian Bauer wrote:

> On Tue, Jun 05, 2001 at 06:18:55AM +0200, Gwenole Beauchesne wrote:
> > I think we have to come up with a subterfuge to fool the compiler's data
> > flow analyzer.
>
> "volatile"?

Yes but according to Brian that doesn't seem to do the trick though it
should unless there is a bug in SGI C++ compiler ?

Anyway, I commit the change with "volatile" for now.

Re: [B2-devel] config problems

[Christian B. <cb...@st...>]

Hi!

On Tue, Jun 05, 2001 at 06:18:55AM +0200, Gwenole Beauchesne wrote:
> I think we have to come up with a subterfuge to fool the compiler's data
> flow analyzer.

"volatile"?

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] config problems

[<gb...@di...>]

Hi,

> - the "extern "C" void exit(int) throw();" lines in the configure test
>   programs were interfering with a "extern void exit(int);"
>   declaration in SGI's unistd.h.  Deleting the " throw()"s fixed it.
>   (Note:  when I run autoconf 2.13 directly, it doesn't have this
>   problem.)

Hmm, I don't know where does this throw() comes from but I recently
realized it was added in autoconf for some Linux distributions...

> - the extended signal handlers test program was failing.  Eventually I
>   tracked it down to SGI's C++ compiler:  it was optimizing out one of
>   the writes to the page[] array, and moving the read of
>   handler_called above the writes.  Here's a patch which fixed it.
>   Just declaring the variables volatile doesn't seem to do it; I had
>   to insert the system call to force synchronization:

What about the test for a sigcontext subterfuge ?
[According to what you have said, I expect it to fail too]

> There's probably a cleaner way to do this... but it works.  I probably
> didn't see this problem before since I always ran configure with my
> local machine's environment instead of the official SGI freeware build
> environment, which may have changed the level of optimization used
> while configuring.

Thanks, your SGI compiler is definitely a really good optimizing
compiler. ;-)

I think we have to come up with a subterfuge to fool the compiler's data
flow analyzer. Something like a fake use after each write.

Brian, is your compiler still optimizing enough to inline a function
defined after its call is issued ? Let's have for example:

static void foo(int *);

int main() {
  int some_int;
  foo(&some_int);
}

void foo(int *) {
  printf("foo\n");
}

Is foo() inlined into the main() function ?

Thanks,
Gwenol=E9.

[B2-devel] config problems

[Brian J. <bjj...@us...>]

I just tried getting the 0.9 snapshot to configure and build in SGI's
internal freeware build environment.  I ran into a few problems:

- the "extern "C" void exit(int) throw();" lines in the configure test
  programs were interfering with a "extern void exit(int);"
  declaration in SGI's unistd.h.  Deleting the " throw()"s fixed it.
  (Note:  when I run autoconf 2.13 directly, it doesn't have this
  problem.)

- the extended signal handlers test program was failing.  Eventually I
  tracked it down to SGI's C++ compiler:  it was optimizing out one of
  the writes to the page[] array, and moving the read of
  handler_called above the writes.  Here's a patch which fixed it.
  Just declaring the variables volatile doesn't seem to do it; I had
  to insert the system call to force synchronization:

--- sigsegv.cpp~        Sun May 20 22:21:54 2001
+++ sigsegv.cpp Mon Jun  4 14:20:44 2001
@@ -250,9 +250,9 @@
 #include <fcntl.h>
 #include <sys/mman.h>
 
-static caddr_t page = 0;
+static volatile caddr_t page = 0;
 static int page_size;
-static int handler_called = 0;
+static volatile int handler_called = 0;
 
 static bool sigsegv_test_handler(sigsegv_address_t fault_address, sigsegv_address_t instruction_address)
 {
@@ -281,6 +281,8 @@
        page[123] = 45;
        page[123] = 45;
 
+       (void)close(zero_fd);   // Be sure to read handler_called after writes!
+
        if (handler_called != 1)
                return 1;
 

There's probably a cleaner way to do this... but it works.  I probably
didn't see this problem before since I always ran configure with my
local machine's environment instead of the official SGI freeware build
environment, which may have changed the level of optimization used
while configuring.

						Brian

--------------------------------------------------------------------

   "There is the greatest practical benefit in making a few failures
    early in life."
                                           -- Thomas Henry Huxley