Closed Bug 331827 Opened 18 years ago Closed 18 years ago

illegal instruction executed on mac os x86

Categories

(Core :: XPConnect, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: rginda, Assigned: mark)

Details

Attachments

(5 files)

There doesn't seem to be a bugzilla component for xpcom/xptcall any more, so I guess maybe this could be classified as a build config issue.  Either way, I'll try to find an owner on IRC tomorrow.

A custom build on a mac os x86 MacbookPro exits after XPCOM registration when it attempts to execute an illegal instruction.  I imagine this is a problem with xptcall build goop.  Build log an stack trace on the way.
Attached file stack trace from gdb
Attached file build log from xpcom/
Other notes:

I'm building this with the gtk2 toolkit, using a small patch from darwin-ports.  I'll attach the patch.

XP_MACOSX is *not* defined by this configuration.  Maybe XP_UNIX is supposed to be enough, I'm not really sure.  I tried hand-hacking a "#define XP_MACOSX" into the xptcinvoke_unixish_x86.cpp.  That moved the illegal instruction elsewhere.
this is the patch from darwin-ports to teach mozilla how to build for x11 on darwin.
Assignee: nobody → mark
The xpconnect component's in core.

At the very least, we'll also need to pick up the OS X code in xptcstubs_unixish_x86.cpp too.  I'll take a look at this tonight.
Component: Build Config → XPConnect
Product: Firefox → Core
Version: unspecified → Trunk
Is your OS_ARCH Darwin? That should be enough to define XP_MACOSX unless I'm missing something. I think we should be defining XP_MACOSX here.
Yeah, my OS_ARCH is darwin.  I'm not sure why XP_MACOSX isn't getting defined.  I put a debug statement in the configure around line 5382, and it triggered.  For some reason, HOST_CFLAGS isn't being respected.  Probably a good thing for me, since it includes -DNO_X11, and I *want* x11.

If I hack a "#define XP_MACOSX" into mozila-config.h my build fails, but I forgot to save the error message.

If I hack a "#define XP_MACOSX" into xptcprivate.h, things *seem* to work.  Mozilla starts and I seem to be able to use it normally.
XP_MACOSX is NOT defined unless you're using a Mac-specific widget toolkit.  I thought it was too.  I was wrong:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1636&mark=4044,4089#4038

We should look at changing this behavior to define XP_MACOSX whenever you're targeting a Mac (as Benjamin and I thought we were doing), and using widget ifdefs to control widget implementations.

XP_MACOSX is defined in HOST_CFLAGS for Darwin build hosts, but HOST_CFLAGS is only used to build host programs.
This makes xptcstubs consistent with xptcinvoke about using KEEP_STACK_16_BYTE_ALIGNED instead of using the XP_MACOSX platform check.  It also moves the platform check from the header into the Makefile, where it's possible to check $(OS_ARCH).

The other changes in xptcstubs are because I had a lot of trouble with the three separate asm blocks, especially when the stack pointer was being left in a random non-ABI-conforming state between the second and third block.  The compiler doesn't recognize when you tell it that you've trashed the stack pointer, and I'm afraid that a future optimizing compiler might try to do something in between blocks and fail.  I already made a similar change in xptcinvoke.
Attachment #216488 - Flags: review?(joshmoz)
This patch fixes the broken things in a gtk2/darwin nonstatic build:

nsMacUtils (universal binary check) should not be present because we don't link against CoreFoundation.

cairo should bring in freetype includes as OS_INCLUDES and not LOCAL_INCLUDES, so that they come AFTER the Moz includes.  (I was getting the system-installed libpixman headers which were out of date and wouldn't work with the in-tree Cairo.)

libxul should be named libxul.dylib and not XUL.  When Mac widgets are not selected, Firefox looks for libxul.dylib, the XULRunner packager does not attempt to do Mac packaging, and nsXPCOMPrivate.h does not look for XUL.framework.

libbrowsercomps should link against glib when the nsGNOMEShellService is built.  (This is the bug solved by the DarwinPorts patch.)
Attachment #216489 - Flags: review?(benjamin)
Comment on attachment 216488 [details] [diff] [review]
Make xptcall align the stack for all $(OS_ARCH) == "Darwin"

looks good
Attachment #216488 - Flags: review?(joshmoz) → review+
Attachment #216488 - Flags: superreview?(shaver)
Comment on attachment 216489 [details] [diff] [review]
Provisional build patch

Fx static builds in at least some configurations are still broken because the final binary is not linked with -lXft.
Comment on attachment 216488 [details] [diff] [review]
Make xptcall align the stack for all $(OS_ARCH) == "Darwin"

shaver sez:
sr=shaver
Attachment #216488 - Flags: superreview?(shaver) → superreview+
Comment on attachment 216489 [details] [diff] [review]
Provisional build patch

I'm not sure I understand why mac+gtk2 shouldn't build macutils and whatnot,  but I don't mind what you've got here if you've got a long-term plan brewing.
Attachment #216489 - Flags: review?(benjamin) → review+
Both patches have been checked in on the trunk.

It would have been pointless to build nsMacUtils and bring in CoreFoundation just for it when the only consumers of nsMacUtils are in #ifdef XP_MACOSX.

For the short term, I just wanted to get the gtk2/Darwin build back in shape.  As things stand now, it doesn't think it's XP_MACOSX, it thinks it's pure XP_UNIX, with no Mac-isms at all.  Some of the Mac-isms like nsMacUtils should arguably be part of a gtk2/Darwin build, but that really requires going through a bunch of ifdefs and deciding what belongs where.  That's a possible long-term direction, but it'll have to happen elsewhere, unless there's enough community resistance and they want the gtk2/Darwin build to remain XP_UNIX only.  That might actually be best, to allow support for people running Darwin without OS X on top, but to allow primary development on that build to be conducted on Darwin + OS X.

Either way, it's like a tier-7 platform.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: