bal instruction in gcc 3.x

bal instruction in gcc 3.x

[Kishore K]

We are facing a problem when U-boot is compiled with gcc 3.x

U-boot  uses the following instruction in one of the files.

bal jump_to_symbol

This code gets compiled without any problem with gcc2. However, if I
compile the code
with gcc3, it exits with the error "Cannot branch to unknown symbol".

What should we do to circumvent this problem ?

I replaced 

bal jump_to_symbol 

by

la t9, jump_to_symbol
jalr t9

Then code gets compiled properly without any problem. Please let me
know, whether this
is correct way of fixing the problem. I am newbie to MIPS assembly
language. Why this
change is required with gcc 3.x compiler ?


TIA,
--kishore

Re: bal instruction in gcc 3.x

[Ralf Baechle]

On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:

> We are facing a problem when U-boot is compiled with gcc 3.x
> 
> U-boot  uses the following instruction in one of the files.
> 
> bal jump_to_symbol
> 
> This code gets compiled without any problem with gcc2. However, if I
> compile the code
> with gcc3, it exits with the error "Cannot branch to unknown symbol".
> 
> What should we do to circumvent this problem ?
> 
> I replaced 
> 
> bal jump_to_symbol 
> 
> by
> 
> la t9, jump_to_symbol
> jalr t9
> 
> Then code gets compiled properly without any problem. Please let me
> know, whether this
> is correct way of fixing the problem. I am newbie to MIPS assembly
> language. Why this
> change is required with gcc 3.x compiler ?

FIrst of all, gcc doesn't care at all about your assembler code, that's
the assembler which you must have changed along with that.

There used to be no relocation type to represent a branch to an external
symbol in an ELF file which is why gas is throwing an error message, so
gas is throwing an error message.  Latest gas fixed that shortcoming.
I think there was a bug in somewhat older gas which resulted in such
invalid code actually being accepted even though it shouldn't have been.

  Ralf

Re: bal instruction in gcc 3.x

[Kishore K]

On 7/19/05, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:
> 
> > We are facing a problem when U-boot is compiled with gcc 3.x
> >
> > U-boot  uses the following instruction in one of the files.
> >
> > bal jump_to_symbol
> >
> > This code gets compiled without any problem with gcc2. However, if I
> > compile the code
> > with gcc3, it exits with the error "Cannot branch to unknown symbol".
> >
> > What should we do to circumvent this problem ?
> >
> > I replaced
> >
> > bal jump_to_symbol
> >
> > by
> >
> > la t9, jump_to_symbol
> > jalr t9
> >
> > Then code gets compiled properly without any problem. Please let me
> > know, whether this
> > is correct way of fixing the problem. I am newbie to MIPS assembly
> > language. Why this
> > change is required with gcc 3.x compiler ?
> 
> FIrst of all, gcc doesn't care at all about your assembler code, that's
> the assembler which you must have changed along with that.
> 
> There used to be no relocation type to represent a branch to an external
> symbol in an ELF file which is why gas is throwing an error message, so
> gas is throwing an error message.  Latest gas fixed that shortcoming.
> I think there was a bug in somewhat older gas which resulted in such
> invalid code actually being accepted even though it shouldn't have been.
> 
>   Ralf

Thank you very much for the reply.

First of all code got compiled only after removing the option
-mips-allow-branch-to-undefined from Makefile. If this option is
included, compilation fails saying that option is invalid. I am using
binutils-2.14.90.06.
Same problem is observed even with binutils 2.15.94.0.2.2. 

Do you mean to say that no change is required in the code snippet 

bal jump_to_symbol

and code should get compiled with the latest assembler without any
problem. Please clearify.

TIA,
--kishore

Re: bal instruction in gcc 3.x

[Pete Popov]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]


Try the attached patch instead.

Pete

On Tue, 2005-07-19 at 22:49 +0530, Kishore K wrote:
> On 7/19/05, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:
> > 
> > > We are facing a problem when U-boot is compiled with gcc 3.x
> > >
> > > U-boot  uses the following instruction in one of the files.
> > >
> > > bal jump_to_symbol
> > >
> > > This code gets compiled without any problem with gcc2. However, if I
> > > compile the code
> > > with gcc3, it exits with the error "Cannot branch to unknown symbol".
> > >
> > > What should we do to circumvent this problem ?
> > >
> > > I replaced
> > >
> > > bal jump_to_symbol
> > >
> > > by
> > >
> > > la t9, jump_to_symbol
> > > jalr t9
> > >
> > > Then code gets compiled properly without any problem. Please let me
> > > know, whether this
> > > is correct way of fixing the problem. I am newbie to MIPS assembly
> > > language. Why this
> > > change is required with gcc 3.x compiler ?
> > 
> > FIrst of all, gcc doesn't care at all about your assembler code, that's
> > the assembler which you must have changed along with that.
> > 
> > There used to be no relocation type to represent a branch to an external
> > symbol in an ELF file which is why gas is throwing an error message, so
> > gas is throwing an error message.  Latest gas fixed that shortcoming.
> > I think there was a bug in somewhat older gas which resulted in such
> > invalid code actually being accepted even though it shouldn't have been.
> > 
> >   Ralf
> 
> Thank you very much for the reply.
> 
> First of all code got compiled only after removing the option
> -mips-allow-branch-to-undefined from Makefile. If this option is
> included, compilation fails saying that option is invalid. I am using
> binutils-2.14.90.06.
> Same problem is observed even with binutils 2.15.94.0.2.2. 
> 
> Do you mean to say that no change is required in the code snippet 
> 
> bal jump_to_symbol
> 
> and code should get compiled with the latest assembler without any
> problem. Please clearify.
> 
> TIA,
> --kishore
> 

[-- Attachment #2: mips_jalr.diff --]
[-- Type: text/x-patch, Size: 1052 bytes --]

--- start.S	2004-02-06 17:27:17.000000000 -0800
+++ start.S~jalr	2005-01-29 16:13:18.000000000 -0800
@@ -234,21 +234,35 @@
 	li	t0, CONF_CM_UNCACHED
 	mtc0	t0, CP0_CONFIG
 
+	/* Initialize GOT pointer.
+	 */
+	bal	1f
+	nop
+	.word	_GLOBAL_OFFSET_TABLE_ - 1f + 4
+1:
+	move	gp, ra
+	lw	t1, 0(ra)
+	add	gp, t1
+
+
 #ifdef CONFIG_INCA_IP
 	/* Disable INCA-IP Watchdog.
 	 */
-	bal	disable_incaip_wdt
+	la	t9, disable_incaip_wdt
+	jalr	t9
 	nop
 #endif
 
 	/* Initialize any external memory.
 	 */
-	bal	memsetup
+	la	t9, memsetup
+	jalr	t9
 	nop
 
 	/* Initialize caches...
 	 */
-	bal	mips_cache_reset
+	la	t9, mips_cache_reset
+	jalr	t9
 	nop
 
 	/* ... and enable them.
@@ -260,21 +274,13 @@
 	/* Set up temporary stack.
 	 */
 	li	a0, CFG_INIT_SP_OFFSET
-	bal	mips_cache_lock
+	la	t9, mips_cache_lock
+	jalr	t9
 	nop
 
 	li	t0, CFG_SDRAM_BASE + CFG_INIT_SP_OFFSET
 	la	sp, 0(t0)
 
-	/* Initialize GOT pointer.
-	 */
-	bal	1f
-	nop
-	.word	_GLOBAL_OFFSET_TABLE_ - 1f + 4
-1:
-	move	gp, ra
-	lw	t1, 0(ra)
-	add	gp, t1
 	la	t9, board_init_f
 	j	t9
 	nop

Re: bal instruction in gcc 3.x

[Maciej W. Rozycki]

On Tue, 19 Jul 2005, Pete Popov wrote:

> Try the attached patch instead.

 Apart from other changes why not simply s/bal/jal/?  Your proposed code 
is bad if ever to be built to a 64-bit object.

  Maciej

Re: bal instruction in gcc 3.x

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Tue, 19 Jul 2005, Pete Popov wrote:
> 
> > Try the attached patch instead.
> 
>  Apart from other changes why not simply s/bal/jal/?  Your proposed code 
> is bad if ever to be built to a 64-bit object.

Non-PIC jal isn't relocateable, the PIC jal wants a regular stack
frame, and the end of the patch shows the 32bit assumption was
already made earlier. :-)


Thiemo

Re: bal instruction in gcc 3.x

[Kishore K]

On 7/20/05, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Tue, 19 Jul 2005, Pete Popov wrote:
> 
> > Try the attached patch instead.
> 
>  Apart from other changes why not simply s/bal/jal/?  Your proposed code
> is bad if ever to be built to a 64-bit object.
> 
In the case of s/bal/jal, I get the warning "No .cprestore pseudo-op
used in PIC code".
Is it safe to ignore this warning ?

On the other hand, if I replace 

bal jump_to_label   

by 

la t9, jump_to_label
jalr t9

I don't see any warning. What could be the reason ?

Can you suggest, what should be done to make the code safe for
building on 64 bit processor.

--kishore

Re: bal instruction in gcc 3.x

[Maciej W. Rozycki]

On Wed, 20 Jul 2005, Thiemo Seufer wrote:

> >  Apart from other changes why not simply s/bal/jal/?  Your proposed code 
> > is bad if ever to be built to a 64-bit object.
> 
> Non-PIC jal isn't relocateable, the PIC jal wants a regular stack
> frame, and the end of the patch shows the 32bit assumption was
> already made earlier. :-)

 Hmm, the joys of inconsistency -- oh well...

  Maciej

Re: bal instruction in gcc 3.x

[Maciej W. Rozycki]

On Wed, 20 Jul 2005, Kishore K wrote:

> On the other hand, if I replace 
> 
> bal jump_to_label   
> 
> by 
> 
> la t9, jump_to_label
> jalr t9
> 
> I don't see any warning. What could be the reason ?

 Implicit assumptions in the "jal" macro.

> Can you suggest, what should be done to make the code safe for
> building on 64 bit processor.

 In this case:

	dla	t9, jump_to_label
	jalr	t9

Though we actually have auxiliary macros to make the resulting code 
readable.  So in the end you should really use something like this:

#include <asm/asm.h>

	PTR_LA	t9, jump_to_label
	jalr	t9

letting the whole mess be hidden in headers.

  Maciej

Re: bal instruction in gcc 3.x

[Alexander Voropay]

<hellokishore@gmail.com> wrote:

>>> However, if I compile the code with gcc3, it exits with the
>>>error "Cannot branch to unknown symbol".

> On the other hand, if I replace 
> 
> bal jump_to_label   
> 
> by 
> 
> la t9, jump_to_label
> jalr t9
> 
> I don't see any warning. What could be the reason ?


1) With "jal label " you'll have a MIPS_26 RELOC type in the ELF obj file:

  jal  lablel

00000000 <.text>:
   0:   0c000000        jal     0x0
   4:   00000000        nop

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 R_MIPS_26         label


2) The "la r,label" is a syntetic inctruction wich expanded into two:
"lui r,%hi label  ; addui r,%lo label". It gives you two RELOCs:

  la  t0, label
  jalr t0

00000000 <.text>:
   0:   3c080000        lui     t0,0x0
   4:   25080000        addiu   t0,t0,0
   8:   0100f809        jalr    t0
   c:   00000000        nop

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 R_MIPS_HI16       label
00000004 R_MIPS_LO16       label

3) AFAIK (correct me), there is no MIPS-specific RELOC type for
the "branch"  instruction format in the BFD, so "bal" to the *external*
symbols is impossible.

May be, old gas generates something like RELOC_PCREL
for "bal external" ?


--
-=AV=-

Re: bal instruction in gcc 3.x

[Alexander Voropay]

<hellokishore@gmail.com> wrote:

>>> However, if I compile the code with gcc3, it exits with the
>>>error "Cannot branch to unknown symbol".

> On the other hand, if I replace 
> 
> bal jump_to_label   
> 
> by 
> 
> la t9, jump_to_label
> jalr t9
> 
> I don't see any warning. What could be the reason ?


1) With "jal label " you'll have a MIPS_26 RELOC type in the ELF obj file:

  jal  lablel

00000000 <.text>:
   0:   0c000000        jal     0x0
   4:   00000000        nop

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 R_MIPS_26         label


2) The "la r,label" is a syntetic inctruction wich expanded into two:
"lui r,%hi label  ; addui r,%lo label". It gives you two RELOCs:

  la  t0, label
  jalr t0

00000000 <.text>:
   0:   3c080000        lui     t0,0x0
   4:   25080000        addiu   t0,t0,0
   8:   0100f809        jalr    t0
   c:   00000000        nop

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 R_MIPS_HI16       label
00000004 R_MIPS_LO16       label

3) AFAIK (correct me), there is no MIPS-specific RELOC type for
the "branch"  instruction format in the BFD, so "bal" to the *external*
symbols is impossible.

May be, old gas generates something like RELOC_PCREL
for "bal external" ?


--
-=AV=-

Re: bal instruction in gcc 3.x

[Maciej W. Rozycki]

On Wed, 20 Jul 2005, Alexander Voropay wrote:

> 3) AFAIK (correct me), there is no MIPS-specific RELOC type for
> the "branch"  instruction format in the BFD, so "bal" to the *external*
> symbols is impossible.

 There is a reloc called BFD_RELOC_16_PCREL_S2 which is used for branches 
by BFD internally, but unfortunately the original SysV ELF supplement for 
MIPS failed to define an appropriate relocation for this purpose (there is 
useless R_MIPS_PC16, though), so there is nothing to map this internal 
relocation to.  There were discussions as to whether reuse R_MIPS_PC16 for 
branches or not.  Unfortunately I don't remember the conclusion -- you'd 
have to find it out yourself.

  Maciej

Re: bal instruction in gcc 3.x

[Thiemo Seufer]

Alexander Voropay wrote:
> <hellokishore@gmail.com> wrote:
> 
> >>>However, if I compile the code with gcc3, it exits with the
> >>>error "Cannot branch to unknown symbol".
> 
> >On the other hand, if I replace 
> >
> >bal jump_to_label   
> >
> >by 
> >
> >la t9, jump_to_label
> >jalr t9
> >
> >I don't see any warning. What could be the reason ?
> 
> 
> 1) With "jal label " you'll have a MIPS_26 RELOC type in the ELF obj file:
> 
>  jal  lablel
> 
> 00000000 <.text>:
>   0:   0c000000        jal     0x0
>   4:   00000000        nop
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 R_MIPS_26         label
> 
> 
> 2) The "la r,label" is a syntetic inctruction wich expanded into two:
> "lui r,%hi label  ; addui r,%lo label". It gives you two RELOCs:
> 
>  la  t0, label
>  jalr t0
> 
> 00000000 <.text>:
>   0:   3c080000        lui     t0,0x0
>   4:   25080000        addiu   t0,t0,0
>   8:   0100f809        jalr    t0
>   c:   00000000        nop
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE              VALUE
> 00000000 R_MIPS_HI16       label
> 00000004 R_MIPS_LO16       label
> 
> 3) AFAIK (correct me), there is no MIPS-specific RELOC type for
> the "branch"  instruction format in the BFD, so "bal" to the *external*
> symbols is impossible.

There is R_MIPS_PC16 which was ill-defined (missing rightshift for the
immediate) in the old ELF spec and thus unused.

> May be, old gas generates something like RELOC_PCREL
> for "bal external" ?

Old gas/ld used R_MIPS_PC16 without reasonable range checking, IOW it
broke silently for branch spans greater than +-32k.

Implementing external branches for gas/ld with the correct R_MIPS_PC16
definition is somewhere on my TODO list but is unlikely to get priority
any time soon.


Thiemo

Re: bal instruction in gcc 3.x

[Alexander Voropay]

"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

> There were discussions as to whether reuse R_MIPS_PC16 for 
> branches or not.  Unfortunately I don't remember the conclusion -- you'd 
> have to find it out yourself.

http://sourceware.org/ml/binutils/2003-02/msg00447.html  (follow thread)

Seems, binutils people have removed this in more recent binutils versions.
MIPS SDE is more conservative there.

--
-=AV=-

Re: bal instruction in gcc 3.x

[Alexander Voropay]

"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

> There were discussions as to whether reuse R_MIPS_PC16 for 
> branches or not.  Unfortunately I don't remember the conclusion -- you'd 
> have to find it out yourself.

http://sourceware.org/ml/binutils/2003-02/msg00447.html  (follow thread)

Seems, binutils people have removed this in more recent binutils versions.
MIPS SDE is more conservative there.

--
-=AV=-

Re: bal instruction in gcc 3.x

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Wed, 20 Jul 2005, Alexander Voropay wrote:
> 
> > 3) AFAIK (correct me), there is no MIPS-specific RELOC type for
> > the "branch"  instruction format in the BFD, so "bal" to the *external*
> > symbols is impossible.
> 
>  There is a reloc called BFD_RELOC_16_PCREL_S2 which is used for branches 
> by BFD internally, but unfortunately the original SysV ELF supplement for 
> MIPS failed to define an appropriate relocation for this purpose (there is 
> useless R_MIPS_PC16, though), so there is nothing to map this internal 
> relocation to.  There were discussions as to whether reuse R_MIPS_PC16 for 
> branches or not.  Unfortunately I don't remember the conclusion -- you'd 
> have to find it out yourself.

It is ok to reuse it, but nobody has done the work yet.


Thiemo