[omniORB] Omni on PlayStation2

[Ulf Stoermer]

> > trying to port Omni4 to Sony PlayStation2.
>
> That sounds like fun...

Well, I'm not so sure. Of course, the video processors of that thing
are very powerful, but the main cpu is very slow. I don't have exact
numbers, but just compiling Omni takes around 6 hours.

> > However, when it comes to using the NamingService big trouble arrises.
> > Let's look at two different scenarios:
> >
> > 1. OmniNames is running on a different computer:
> > When running eg3_impl on the Playstation I can see in the trace of
> > omniNames that actually the first GIOP message arrives but upon that
> > it never replies anything.
>
> That's very odd indeed. What does the trace on the client show?  Does
> the Linux omniNames work correctly with a Linux client?

Yes, at the same time the Linux omniNames works well with any other
client, Linux, Windows, MacOS, Zaurus.
The trace on the client side just shows scanning for idle connections
and then after some time:

omniORB: Scan for idle connections done (1048725437,572366000).
omniORB: Scan for idle connections (1048725442,582370000)
omniORB: Scan for idle connections done (1048725442,582370000).
omniORB: inputMessage: from giop:tcp:133.176.227.171:2809 12 bytes
omniORB:
4749 4f50 0102 0105 0000 0000           GIOP........
omniORB: To endpoint: giop:tcp:133.176.227.171:2809. Send GIOP 1.0
MessageError because a protocol error has been detected. Connection is
closed.
omniORB: throw giopStream::CommFailure from
giopImpl10.cc:883(0,MAYBE,COMM_FAILURE_WaitingForReply)
Segmentation fault

At the same time, this is what the trace shows on the omniNames side:

omniORB: Scavenger reduce idle count for strand 0x80665d8 to 0
omniORB: Scavenger close connection from giop:tcp:133.176.227.130:1029
omniORB: Scan for idle connections done (1048789468,514874000).
omniORB: throw giopStream::CommFailure from
giopStream.cc:857(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: Server connection refcount = 1
omniORB: Server connection refcount = 0
omniORB: Server close connection from giop:tcp:133.176.227.130:1029
omniORB: Scan for idle connections (1048789473,524979000)
omniORB: Scan for idle connections done (1048789473,524979000).
omniORB: AsyncInvoker: thread id = 15 has exited. Total threads = 3


> [...]
> > 2. scenario: Both, eg3_impl and omniNames running on PlayStation:
> > In this case omniNames is slightly more eloquent but will soon seg fault
> > after a short 'dialog'. Here the trace of omniNames:
>
> That looks like everything is working as it should, right up until the
> segfault. I don't suppose you can run it under gdb?

Well, I can, but here comes another problem. If I run gdb I get the
following error:
  This GDB was configured as "mipsEEel-linux"...
  (gdb) run
  Starting program: /home/ulf/omniorb/omni401/src/examples/echo/eg3_clt
  BFD: /lib/ld.so.1: invalid string offset 18368 >= 3630 for section
'.dynstr'
  Program received signal ?, Unknown signal.
  0x2aec5530 in __sigsuspend () at __sigsuspend:2
  __sigsuspend:2: No such file or directory.

The same also happens when running eg1 or eg2, which both work correctly
when executed normally. Maybe this in fact has to do with gcc 2.95.2 not
supporting thread safe exceptions.

But even if PlayStation at the moment isn't able to thread safely handle
exceptions, how could this affect the first scenario, where omniNames
runs on a Linux PC and never replies anything?

For the moment I would be just happy to get some client running on
the Playstation that can talk to some server on a PC.


> > P.S.: If you think that PlayStation is a freaky platform for Omni how
> > about this then: Last week I successfully ported it to Sharp Zaurus.
>
> Great!  Do you have any patches?

Not yet (simply too many things to do). The port was done brute force.
The Zaurus runs a Sharp-Linux with only gcc 2.95.3. I've found a webpage
with instructions to install a gcc-2.95.3-ARM-cross-compiler on MacOS-X,
so the compilation was actually done on the Mac. Then I tried to adapt
the arm_vxWorks makefile to my needs. Still got many errors though
and got rid off them by brutally hacking into lots of dir-makefiles and
implementation files. Mostly it had to do with wrong paths and LongDouble
not defined. As already said, I was just interested in getting through
somehow, and actually I did. For the moment it was just an exercise
whether it is possible to get Omni working on there. Maybe when I have
more time I will be able to have a look again and provide a clean patch.

Cheers

Ulf