Ticket #271 (closed bug: fixed)

Opened 5 years ago

Last modified 3 years ago

Parrot crashes on openbsd/sparc64

Reported by: Infinoid Owned by: dukeleto
Priority: normal Milestone:
Component: core Version:
Severity: medium Keywords: gc sparc
Cc: Language:
Patch status: Platform: openbsd

Description

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).

Change History

follow-up: ↓ 2   Changed 5 years ago by whiteknight

  • keywords gc sparc added
  • platform set to openbsd
  • component changed from none to core
  • milestone set to 1.0

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.

in reply to: ↑ 1   Changed 5 years ago by 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.

  Changed 5 years ago by doughera

  • milestone 1.3 deleted

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.

follow-up: ↓ 5   Changed 4 years ago by dukeleto

  • status changed from new to assigned
  • owner set to dukeleto

in reply to: ↑ 4   Changed 3 years ago by 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

  Changed 3 years ago by dukeleto

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.