Closed
Bug 250472
Opened 20 years ago
Closed 15 years ago
Unresolved symbols when building firefox with gcc 3.x.x for mips(el).
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 258429
People
(Reporter: zoran_markovic, Unassigned)
References
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT; IEPackage1) Build Identifier: The generation of assembler stubs done in xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_mips.s.m4 is tailored for gcc version 2.x. It looks like gcc 3.x.x has a new way to mangle symbols which causes some symbols to be unresolved during link. I believe this also applies to mozilla. I found a similar report for arm, but lost it somewhere. I created a new m4 file to be used with gcc3 (with my limited understanding of m4), but the best way to go is to detect the gcc version and create the m4 file accordingly. Attached is the file: ---begin xptcstubs_asm_mips.s.m4-------- /* -*- Mode: asm; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- * Version: MPL 1.1 * * The contents of this file are subject to the Mozilla Public License Version * 1.1 (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * http://www.mozilla.org/MPL/ * * Software distributed under the License is distributed on an "AS IS" basis, * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License * for the specific language governing rights and limitations under the * License. * * The Original Code is mozilla.org code. * * The Initial Developer of the Original Code is * Netscape Communications Corp, Inc. * Portions created by the Initial Developer are Copyright (C) 2001 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Stuart Parmenter <pavlov@netscape.com> * Chris Waterson <waterson@netscape.com> */ /* This code is for MIPS using the O32 ABI. */ #include <sys/regdef.h> #include <sys/asm.h> .text .globl PrepareAndDispatch NARGSAVE=4 # extra space for the callee to use. gccism # we can put our a0-a3 in our callers space. LOCALSZ=2 # gp, ra FRAMESZ=(((NARGSAVE+LOCALSZ)*SZREG)+ALSZ)&ALMASK define(STUB_LEN, `len('`Stub'$1`)') define(STUB_NAME, ``_ZN14nsXPTCStubBase''`STUB_LEN('$1`)'``Stub''$1``Ev'') define(STUB_ENTRY, `` .globl ''`STUB_NAME('$1`)'`` .align 2 .type ''`STUB_NAME('$1`)'``,@function .ent ''`STUB_NAME('$1`)'``, 0 ''`STUB_NAME('$1`)'``: .frame sp, FRAMESZ, ra .set noreorder .cpload t9 .set reorder subu sp, FRAMESZ .cprestore 16 li t0, ''$1`` b sharedstub .end ''`STUB_NAME('$1`)'`` '') define(SENTINEL_ENTRY, `') include(xptcstubsdef.inc) .globl sharedstub .ent sharedstub sharedstub: REG_S ra, 20(sp) REG_S a0, 24(sp) REG_S a1, 28(sp) REG_S a2, 32(sp) REG_S a3, 36(sp) # t0 is methodIndex move a1, t0 # put the start of a1, a2, a3, and stack move a2, sp addi a2, 24 # have a2 point to sp + 24 (where a0 is) # PrepareAndDispatch(that, methodIndex, args) # a0 a1 a2 # jal PrepareAndDispatch REG_L ra, 20(sp) REG_L a1, 28(sp) REG_L a2, 32(sp) addu sp, FRAMESZ j ra .end sharedstub ----end xptcstubs_asm_mips.s.m4--------- Reproducible: Always Steps to Reproduce: 1.Build firefox for mipsel with mipsel-linux-gcc 3.3.3 and glibc 2.3.2 2. 3. Actual Results: Unresolved symbols. Expected Results: Successful build.
Assignee: bryner → BradleyJunk
Component: Build Config → XPConnect
Product: Firefox → Browser
QA Contact: asa → pschwartau
Summary: Unresolved symbols when building firefox with gcc 3.x.x for mips(el). → Unresolved symbols when building firefox with gcc 3.x.x for mips(el).
Version: unspecified → Trunk
Comment 1•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 2•19 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Comment 3•18 years ago
|
||
I'm guessing this is still a real bug, not EXPIRED.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•18 years ago
|
Flags: blocking1.9?
Comment 4•18 years ago
|
||
Need a patch from a MIPS hacker who can test it. I'm an SGI alum, so sentimental, but MIPS Linux is not a tier 1 or 2 platform, so those who care must lift weight. /be
Comment 5•18 years ago
|
||
Brendan, did you read comment 0? It has the fix. The real issue is hooking that fix into our build system.
Comment 6•18 years ago
|
||
I was looking for a tested patch. ;-) /be
Comment 7•18 years ago
|
||
I'd be surprised if that were sufficient. In almost all cases the calling conventions (and thus the necessary assembly) differs between gcc2.9x and gcc3. Timeless, is this one of the bugs on your ports radar?
Updated•18 years ago
|
Assignee: dbradley → nobody
Updated•18 years ago
|
QA Contact: pschwartau → xpconnect
Comment 8•17 years ago
|
||
Not a blocker. We'd gladly take a fix tho.
Flags: blocking1.9? → blocking1.9-
bsmedberg: it doesn't really stick well... i think biesi+someone+myself had access to mips at one point, but i'm not really in a position to write whatever build changes would be needed.
(In reply to comment #7) > I'd be surprised if that were sufficient. In almost all cases the calling > conventions (and thus the necessary assembly) differs between gcc2.9x and gcc3. I think we already have code to take care of that: http://hg.mozilla.org/mozilla-central/annotate/a60b78ae0793/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_mips.s#r140
That said, this is likely a duplicate of bug 258429.
Status: NEW → RESOLVED
Closed: 19 years ago → 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•