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)

SGI
Linux
defect
Not set
normal

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
Hardware: Other → SGI
Depends on: 258429
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/
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
I'm guessing this is still a real bug, not EXPIRED.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
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
Brendan, did you read comment 0?  It has the fix.  The real issue is hooking that fix into our build system.
I was looking for a tested patch. ;-)

/be
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?
Assignee: dbradley → nobody
QA Contact: pschwartau → xpconnect
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 ago15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.