Parrot crashes on openbsd/sparc64

[Infinoid]

janus raised the following concern on IRC this morning:

[04:29] < janus> meh, still no luck on sparc64 (miniparrot dumps core)
[04:38] < janus> src/cpu_dep.c:90: defined(__sparc) -> defined(__sparc__) && !defined(__sparc64__) seems to fix... at least the build continues now
[04:39] < janus> could that be something os-specific?
[04:40] < janus> granted, i'm poking around in an area where others will have more clue

Not knowing anything about the sparc platform, I can think of three possible issues here:

1. I notice Janus replaced __sparc with __sparc__. Is this a portability concern? If so, we should probably check both.

2. Is the assembly code in question even valid on sparc64? Does the instruction width change between sparc32 and sparc64?

3. If the answer to the above question is "yes", then does openbsd allow you to run code on the stack? If not, that might be the cause of the crash (so it might have nothing to do with sparc64).

[whiteknight]

I posted a reply to parrot-dev, but I can post some notes here too for the record:

1) This is a bad solution to the problem, for all the reasons you list (code may not be portable to all Sparc systems, OpenBSD might not execute code on the stack, etc). Also, it's a problem in terms of code readability.

2) If we want to have assembly code, it should be in a separate assembly file, added to the build at configure time, and assembled in the build. None of this hand-assembled stuff, no matter how clever it is.

3) Relying on a complex system of compiler-defined macros to determine the system characteristics is a decent solution, but we should really find a better way to do this through the configuration system instead.

[doughera]

Replying to whiteknight:

I posted a reply to parrot-dev, but I can post some notes here too for the record: 1) This is a bad solution to the problem, for all the reasons you list (code may not be portable to all Sparc systems, OpenBSD might not execute code on the stack, etc). Also, it's a problem in terms of code readability.

A patch to try to start addressing some of this in a simple way was posted to the parrot-dev list in Februrary 2009  http://lists.parrot.org/pipermail/parrot-dev/2009-February/001269.html. I don't recall ever hearing whether it helped on OpenBSD or not. (There might be some minor cc vs. gcc changes, and some tweaks to the sparc defines that would need to be applied as well, but lacking any feedback, I didn't pursue it.

[doughera]

Given that this has been stalled for 4 months, I have removed the 1.3 milestone. I'm not sure why it was put there in the first place.

[jkeenan]

Replying to dukeleto:

dukeleto,

IIRC, on #parrot reports that we have been successful in building Parrot on this platform at the "build farm".

Is that true? If so, can this ticket be closed?

Thank you very much.

kid51