This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with crossgcc and AMD Au1550


Chris Jones wrote:

Dan, Kai etc.

I've debugged it down to NOT a crosstool problem. Crosstool
seems to work fine. The problem is that there seems to be a
problem in the kernel.

I'm trying to compile the zaptel driver for asterisk, and
it includes <asm/uaccess.h> which in my case is really
<asm-mips/uaccess.h>.

The function calls in question are:

get_user(j,(int *)data);
and
put_user(chan->blocksize,(int *)data);

These translate to more or less direct assembly. (Hooray!)

The offending lines are:

uaccess:245  and
uaccess:336 respectively.

A JUMP instruction:

j 2b

This is what the compiler/assembler is complaining about:

/tmp/ccGn3TTn.s: Assembler messages:
/tmp/ccGn3TTn.s:7766: Error: Cannot branch to symbol in another section.
/tmp/ccGn3TTn.s:7817: Error: Cannot branch to symbol in another section.

I have no clue for this but asking this on the GNU binutils maillist could tell something more, one year ago there were discussion about warnings and errors for these issues and I had two msgs from Chris Demetriou in my local maillist archives, the first told :

------------------- clip --------------------------------------------------
To: binutils@sources.redhat.com
Subject: [patch RFA] revisit MIPS warning re: global symbols as branch
 targets.
From: cgd@broadcom.com
Date: 01 Jul 2003 10:23:02 -0700

So, i was just compiling some stuff, and i noticed the warning (again 8-):

Warning: Pretending global symbol used as branch target is local.

Is there ** any ** reason to issue that warning when
(mips_pic == NO_PIC)?

There may be a reason for the warning (to prevent a problem of
understanding) for people doing userland work and trying to hard-code
branches to symbols in shared libraries that they expect to be
overridden, or something.

However, if i'm writing a kernel (oh so not PIC, at least in my world
8-), i should be able to make functions global or not and i should be
able to branch to them w/o getting warning.


(Hmm, is it necessary to leave the rest of the code alone, in this case, for proper operation? certainly, it's easiest to do so... I suspect if you left the branch target as-is it would turn out OK... but better to use the more well-tested code path, eh? 8-)


anyway, tested on mipsisa64sb1-elf and mips-linux w/ the gas/etc. testsuite. (causes no change in behaviour other than the warning, so i'm not worried about more than that. 8-)


cgd -- [ gas/ChangeLog ] 2003-07-01 Chris Demetriou <cgd@broadcom.com>

	* config/tc-mips.c (mips_validate_fix): Do not warn about branch
	target being a global symbol if not compiling PIC code.

<snip>

-.*:25: Warning: Pretending global symbol used as branch target is local.
-.*:26: Warning: Pretending global symbol used as branch target is local.
 .*:35: Error: Cannot branch to undefined symbol.
 .*:36: Error: Cannot branch to undefined symbol.
 .*:37: Error: Cannot branch to symbol in another section.
Index: testsuite/gas/mips/branch-misc-2pic.l
===================================================================
RCS file: testsuite/gas/mips/branch-misc-2pic.l
diff -N testsuite/gas/mips/branch-misc-2pic.l
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ testsuite/gas/mips/branch-misc-2pic.l	1 Jul 2003 17:21:55 -0000
@@ -0,0 +1,10 @@
+.*: Assembler messages:
+.*:21: Warning: Pretending global symbol used as branch target is local.
+.*:22: Warning: Pretending global symbol used as branch target is local.
+.*:23: Warning: Pretending global symbol used as branch target is local.
+.*:24: Warning: Pretending global symbol used as branch target is local.
+.*:25: Warning: Pretending global symbol used as branch target is local.
+.*:26: Warning: Pretending global symbol used as branch target is local.
+.*:35: Error: Cannot branch to undefined symbol.
+.*:36: Error: Cannot branch to undefined symbol.
+.*:37: Error: Cannot branch to symbol in another section.
Index: testsuite/gas/mips/branch-misc-2pic.s
===================================================================
RCS file: testsuite/gas/mips/branch-misc-2pic.s
diff -N testsuite/gas/mips/branch-misc-2pic.s
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ testsuite/gas/mips/branch-misc-2pic.s	1 Jul 2003 17:21:55 -0000
@@ -0,0 +1,43 @@
+# Source file used to test the backward branches to globals in this file.
+
+	.globl g1 .text
+	.globl g2 .text
<snip>
+	b	x1
+	b	x2
+	b	.Ldata
+
------------------- clip --------------------------------------------------

 So cgd provided patches for removing some warnings from 'gas' and new
testsuites for testing these things...

 Maybe Chris or some other MIPS specialist could be interested to look at the
inline asm in the Linux 2.4 kernel, whether it is totally wrong or not... The
known fact in MIPS ABI for SVR4 and most probably for Linux too, as I remember
it, is that everything, including the so called 'static' binaries, should be
in PIC code. So if something doesn't fit to the PIC model, it will be handled
being wrong... Maybe these inline asm's are missing some '.noabicalls' or
something, the C module compile options not using the '-fno-PIC' or something.
Older 'gas' versions may have accepted things but newer assemblers then care
more about following the MIPS ABI...

 Anyway I would suspect again this mess with non-PIC and PIC code being mixed.
Some MIPS SVR4.2's really had C libraries where there were static modules in
non-PIC mode and all the shared libs of course were in PIC... And then GNU ld
couldn't link non-PIC and PIC code together because the MIPS ABI doesn't
allow this meanwhile the native 'ld' on the systems didn't have any troubles
with this... Producing cross-GCCs for them therefore was more than tough if
desperately trying to use all the original libs. Rebuilding the offending
library routines to be in PIC format and to comply with the MIPS ABI was one
possibility.

Cheers, Kai




------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]