Re: --target=v850-unknown-elf, linker problem

Re: --target=v850-unknown-elf, linker problem

[Torsten Mohr]

Hi,

> To my untrained eye, this looks a little like a bug. In
> v850/lib1funcs.asm, .L_return_interrupt should IMHO be in the
> .call_table_text section, not .text. (Would you like to try making the
> change? It's still line 1459 in 3.4.4) We might be able to sneak in a
> fix before the experts arrive with more sage advice. ;-)

great, thanks for that hint, i just uncommented the ".text" in
line 1459 in lib1funcs.asm (for gcc-3.4.4).  Now the code links
fine.

I wonder now how to proceed, do i need to report this stuff officially
somewhere?  I also got no answer to my mail from saturday morning,
subject line "-mwarn-signed-overflow".  I had to do that change to
make gcc-3.4.4 compile.


Best regards,
Torsten.


>
> That said, using v850e-gcc 3.3, I found the easiest way to make all the
> callt pain go away was to turn off compiler optimisation. (Although I
> only have a fortnight's experience with the v850, so far it seems that
> v850e-gcc 3.3 defaults to conventional push/pop sequences, in lieu of
> the callt size optimisation. So there is no .call_table_data to
> complicate initial attempts to get things to compile, if optimisation is
> turned off. Version 3.4.4 may do the same.)
>
> Adding your source lines to my first chunk of test code generated what was
> expected:
>
> 00402000 <_irq_nmi>:
>   402000:   5c 1a          add   -4, sp
>   402002:   63 ef 01 00    st.w  r29, 0[sp]
>   402006:   03 e8          mov   sp, r29
>   402008:   1d 18          mov   r29, sp
>   40200a:   23 ef 01 00    ld.w  0[sp],r29
>   40200e:   44 1a          add   4, sp
>   402010:   7f 00          jmp   [lp]
>
> (And no errors. :-)
>
> > When i don't use -mv850e, but use -mv850, all works fine.
>
>    IIUC that's because mv850 doesn't have the callt instruction, so the
> problematic optimisation is not invoked.
>
>    I still don't fully grok the callt stuff either, so best of luck.
>
> hth,
> Erik

Re: --target=v850-unknown-elf, linker problem

[Erik Christiansen]

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

On Mon, Aug 15, 2005 at 07:55:00PM +0200, Torsten Mohr wrote:
> I wonder now how to proceed, do i need to report this stuff officially
> somewhere? 

I've taken the liberty of cleaning up the L_callt_save_interrupt
#ifdef, making it consistent with the following one for
L_callt_save_all_interrupt. (This not only removes the .text error, but
adopts the easier to handle layout of the latter.)

Would you mind applying the attached patch, and rebuilding v850e-gcc, to
check it works for you? I'd happily have a look at the elf generated
from a small test, if you'd like to send it off-list. (Just the
.call_table_data and .call_table_text sections would suffice.) Once
we're happy with it, I'll put the bug report and patch into bugzilla.

I'm happy to move over to a gcc mailing list, but am not currently
subscribed.

Erik

[-- Attachment #2: lib1funcs.patch --]
[-- Type: text/plain, Size: 2216 bytes --]

--- /mnt/usr/local/src/gcc-3.4.4/gcc/config/v850/lib1funcs.asm	Thu Jan  1 04:22:33 2004
+++ /home/erik/tmp/lib1funcs.asm	Tue Aug 16 12:05:36 2005
@@ -1428,7 +1428,7 @@
 
 	
 #ifdef	L_callt_save_interrupt
-	/* Put this functions into the call table area */
+	/* Put these functions into the call table area */
 	.call_table_text
 	
 	/* Save registers r1, ep, gp, r10 on stack and load up with expected values.  */
@@ -1440,23 +1440,14 @@
         st.w    ep,  0[sp]
         st.w    gp,  4[sp]
         st.w    r1,  8[sp]
-        /* R10 has alread been saved bofore callt ctoff(_save_interrupt).  */
+        /* R10 has alread been saved before callt ctoff(_save_interrupt).  */
         /* st.w    r10, 12[sp]  */
 	mov	hilo(__ep),ep
 	mov	hilo(__gp),gp
 	ctret
 
-        /* Place the offsets of the start of the routine into the call table.  */
-        .call_table_data
-        .global __callt_save_interrupt
-        .type   __callt_save_interrupt,@function
-__callt_save_interrupt: .short ctoff(.L_save_interrupt)
-
-        .call_table_text
-
 	/* Restore saved registers, deallocate stack and return from the interrupt.  */
-        /* Called via:  callt ctoff(__callt_restore_itnerrupt).  */
-	.text
+        /* Called via:  callt ctoff(__callt_restore_interrupt).  */
 	.align	2
 	.globl	__return_interrupt
 	.type	__return_interrupt,@function
@@ -1472,9 +1463,13 @@
         addi    24, sp, sp
         reti
 
-	/* Place the offsets of the start of the routine into the call table.  */
+	/* Place the offsets of the start of these routines into the call table.  */
 	.call_table_data
 
+        .global __callt_save_interrupt
+        .type   __callt_save_interrupt,@function
+__callt_save_interrupt:         .short ctoff(.L_save_interrupt)
+
         .global __callt_return_interrupt
         .type   __callt_return_interrupt,@function
 __callt_return_interrupt:       .short ctoff(.L_return_interrupt)
@@ -1482,7 +1477,7 @@
 #endif /* L_callt_save_interrupt */
 
 #ifdef L_callt_save_all_interrupt
-	/* Put this functions into the call table area.  */
+	/* Put these functions into the call table area.  */
 	.call_table_text
 	
 	/* Save all registers except for those saved in __save_interrupt.  */

Re: --target=v850-unknown-elf, linker problem

[Torsten Mohr]

Hi,

> I've taken the liberty of cleaning up the L_callt_save_interrupt
> #ifdef, making it consistent with the following one for
> L_callt_save_all_interrupt. (This not only removes the .text error, but
> adopts the easier to handle layout of the latter.)

> Would you mind applying the attached patch, and rebuilding v850e-gcc, to
> check it works for you? I'd happily have a look at the elf generated
> from a small test, if you'd like to send it off-list. (Just the
> .call_table_data and .call_table_text sections would suffice.) Once
> we're happy with it, I'll put the bug report and patch into bugzilla.

great, thanks for that patch.  I've just applied it and reinstalled
the complete toolchain from scratch.

I'll send you the relevant files by private mail, if anybody else
is interested, i can also forward them.


To compile the toolchain i did:

In /rest/tmp i have:
gcc-3.3.4
binutils-2.16
newlib-1.13.0
bbin (empty)
bgcc (empty)
bnl (empty)

In bbin:
../binutils-2.16/configure \
  --target=v850e-unknown-elf \
  --prefix=/opt/v850e-unknown-elf \
  --disable-nls
make
make install

export PATH=/opt/v850e-unknown-elf/bin:$PATH

In bgcc:
../gcc-3.4.4/configure \
  --target=v850e-unknown-elf \
  --prefix=/opt/v850e-unknown-elf \
  --enable-languages="c" \
  --disable-nls
make
make install

In bnl:
../newlib-1.13.0/configure \
  --target=v850e-unknown-elf \
  --prefix=/opt/v850e-unknown-elf \
  --disable-nls
make
make install


Best regards,
Torsten.

Re: --target=v850-unknown-elf, linker problem

[James E Wilson]

Torsten Mohr wrote:
> I wonder now how to proceed, do i need to report this stuff officially
> somewhere?  I also got no answer to my mail from saturday morning,
> subject line "-mwarn-signed-overflow".  I had to do that change to
> make gcc-3.4.4 compile.

gcc bugs can be reported into our bugzilla database.  See
    http://gcc.gnu.org/bugs.html

We are volunteers, and can't always answer every question immediately.
You should not expect mail set on Saturday to be answered before Monday
morning.  Generally, you should allow a week before assuming a message
was missed.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: --target=v850-unknown-elf, linker problem

[James E Wilson]

Erik Christiansen wrote:
> I've taken the liberty of cleaning up the L_callt_save_interrupt
> #ifdef, making it consistent with the following one for
> L_callt_save_all_interrupt. (This not only removes the .text error, but
> adopts the easier to handle layout of the latter.)

Patches should be sent to gcc-patches.  In general, we would need a gcc
copyright assignment, but this is simple enough that we don't need one
for this patch.

Alternatively, patches can be put into bugzilla bug reports.  This will
help make sure it won't get forgotten.

In this case, since you've already sent the patch, and it looks good,
I'll try to take care of this for you.   I'm doing a v850 build now to
verify it and then I plan to add it to gcc mainline so this will be
fixed for the next gcc release, gcc-4.1.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: --target=v850-unknown-elf, linker problem

[Erik Christiansen]

On Wed, Aug 17, 2005 at 12:53:14PM -0700, James E Wilson wrote:
> Alternatively, patches can be put into bugzilla bug reports.  This will
> help make sure it won't get forgotten.

That's where we were headed, as mentioned at the end of a paragraph in
the email with the patch: "Once we're happy with it, I'll put the bug
report and patch into bugzilla." (I shoulda made it a separate para. :-)

> In this case, since you've already sent the patch, and it looks good,
> I'll try to take care of this for you.

It'll only take me a moment, and "try" fits poorly with "make sure it
won't get forgotten". ;-) (Sorry, the years with quality system
responsibilities are showing through.)

> I'm doing a v850 build now to verify it and then I plan to add it to
> gcc mainline so this will be fixed for the next gcc release, gcc-4.1.

If you haven't put it in bugzilla yet, I can free you up for the more
important next gcc release.

Regards,
Erik