This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


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

AW: Renesas __trap34() system calls broken - possibly on other platforms, too


Hello Dave,

>>>> Sadly, I am locked on a Windows machine so compiling newlib is
>>>> extremely painful.
>>> 
>>>   Huh?  It's usually trivial with cygwin.
>> 
>> Only with a gcc that understands cygwin pathnames.
> 
>   Yep, that's basically what I meant when I said "with cygwin".  With
> /cygwin/.  Not with /something else/.  I imagine MSVC won't find it
> easy either ....   ;-)
> 
>> The KPIT toolset is mingw based (IFAIK).
> 
>   Ah.  Still, that shouldn't necessarily imply a problem; mingw is
> not djgpp, and it happily handles posix-style paths.  However, it's
> not nearly as complete a posix emulation as cygwin, so there may be
> some other omission that causes problems; without more information
> from Mark, I can't say. 

1.) Yes, I am lazy. I tried before to compile newlib under Cygwin using
the KPIT mingw based compiler and failed miserably. Why? It takes more
than a work day for a single run, I do not exactly know which parameters
KPIT used to compile and the script KPIT supplies does not only compile
newlib but also gcc, is not easy to understand and tries to pull things
directly from the web which does not work if you sit behind a corporate
firewall.

2.) I will jeopardize the project if do something wrong out of
ignorance. So I am hoping that somebody knowledgeable on the newlib
mailing list agrees that there is a bug in newlib and somebody kind from
KPIT will supply a new version of their toolchain.

3.) This is what happens if you feed a non-DOS-style path to a mingw
gcc:
----------
$ sh-elf-gcc /cygdrive/c/temp/test.c
sh-elf-gcc.exe: /cygdrive/c/temp/test.c: No such file or directory
sh-elf-gcc.exe: no input files
----------
Calling gcc with c:/temp/test.c as the parameter works fine.

>> However, unless the problem is that the whole library was not built
>> with the -mrenesas option, he only really needs to rebuild the
>> syscalls.c file. 
> 
>   Agreed, this is totally a mixing-binaries-with-different-ABIs
> problem. 

Agreed, I could recompile syscalls.c and truncate.c and use ar to
replace it in libc.a and libg.a. But the problem would stay in newlib
until the next poor soul stumbles over it. And the KPIT installation
features 27 versions of libc.a and libg.a, each for another combination
of core, endianess and -mrenesas.

I disagree with the view that it is a
mixing-binaries-with-different-ABIs problem.

1.) printf() works just fine. If it was a MBWDAP, this would not work
either.

2.) I checked which library is pulled in. It is
GNUSHv0603-ELF/sh-elf/sh-elf/lib/mrenesas/ml/m2/libc.a. This is clearly
a library compiled with -mrenesas.

3.) I am compiling and linking with options "-m3 -ml -mrenesas".

4.) I saw exactly this problem before on 100% self written C code where
a variable argument list was used, but no prototype was given at the
point where it was called. Exactly the same behavior was observed. See a
few lines below for an example. My lesson learned was to enable
-Wimplicit-function-declaration all the time.

>> Either way, he really should be asking KPIT for support for KPIT
>> toolset. As I understand it, they will provide a limited amount
>> support free of charge.

Yes, I did that. But I am still 100% convinced that there is a problem
in the source code of newlib. I am pretty sure that the KPIT guys did
nothing wrong.

>   Yes, we often get the KPIT guys turning up here and on the crossgcc
> list, they're very approachable.  Mark, if you don't hear from them
> on this list, it wouldn't be off-topic for you to raise the problem
> at the crossgcc list as well.

I do not think gcc is broken. How should the compiler know when to put
all parameters on the stack because it is a variable argument list
function? According to the Renesas ABI it puts arguments in registers
until there are not enough of them.

To further illustrate this:

This example shows how the caller prepares the arguments if it does not
know that ellipsis() has a variable argument list. It simply puts the
four arguments in R4 to R7. The code was compiled with "sh-elf-gcc -g
-m3 -ml -mrenesas -O0 -c test.c".
----------
$ sh-elf-objdump -S test.o

test.o:     file format elf32-shl

Disassembly of section .text:

00000000 <_test>:
/* int ellipsis(int num, ...); */

int test(void)
{
   0:   e6 2f           mov.l   r14,@-r15
   2:   22 4f           sts.l   pr,@-r15
   4:   fc 7f           add     #-4,r15
   6:   f3 6e           mov     r15,r14
   int sum;

   sum = ellipsis(3, 1, 2, 3);
   8:   03 e4           mov     #3,r4
   a:   01 e5           mov     #1,r5
   c:   02 e6           mov     #2,r6
   e:   03 e7           mov     #3,r7
  10:   07 d1           mov.l   30 <_test+0x30>,r1      ! 0x0 <_test>
  12:   0b 41           jsr     @r1
  14:   09 00           nop     
  16:   e3 61           mov     r14,r1
  18:   c4 71           add     #-60,r1
  1a:   0f 11           mov.l   r0,@(60,r1)

   return sum;
  1c:   e3 61           mov     r14,r1
  1e:   c4 71           add     #-60,r1
  20:   1f 51           mov.l   @(60,r1),r1
  22:   13 60           mov     r1,r0
}
  24:   04 7e           add     #4,r14
  26:   e3 6f           mov     r14,r15
  28:   26 4f           lds.l   @r15+,pr
  2a:   f6 6e           mov.l   @r15+,r14
  2c:   0b 00           rts     
  2e:   09 00           nop     
  30:   00 00           .word 0x0000
        ...
----------

This example shows that the caller puts all the arguments on the stack
if it knows that ellipsis() has a variable argument list. The code was
compiled with "sh-elf-gcc -g -m3 -ml -mrenesas -O0 -c test.c".
----------
$ sh-elf-objdump -S test.o

test.o:     file format elf32-shl

Disassembly of section .text:

00000000 <_test>:
int ellipsis(int num, ...);

int test(void)
{
   0:   e6 2f           mov.l   r14,@-r15
   2:   22 4f           sts.l   pr,@-r15
   4:   fc 7f           add     #-4,r15
   6:   f3 6e           mov     r15,r14
   int sum;

   sum = ellipsis(3, 1, 2, 3);
   8:   f0 7f           add     #-16,r15
   a:   f3 62           mov     r15,r2
   c:   03 e1           mov     #3,r1
   e:   12 22           mov.l   r1,@r2
  10:   01 e1           mov     #1,r1
  12:   11 12           mov.l   r1,@(4,r2)
  14:   02 e1           mov     #2,r1
  16:   12 12           mov.l   r1,@(8,r2)
  18:   03 e1           mov     #3,r1
  1a:   13 12           mov.l   r1,@(12,r2)
  1c:   08 d1           mov.l   40 <_test+0x40>,r1      ! 0x0 <_test>
  1e:   0b 41           jsr     @r1
  20:   09 00           nop     
  22:   10 7f           add     #16,r15
  24:   e3 61           mov     r14,r1
  26:   c4 71           add     #-60,r1
  28:   0f 11           mov.l   r0,@(60,r1)

   return sum;
  2a:   e3 61           mov     r14,r1
  2c:   c4 71           add     #-60,r1
  2e:   1f 51           mov.l   @(60,r1),r1
  30:   13 60           mov     r1,r0
}
  32:   04 7e           add     #4,r14
  34:   e3 6f           mov     r14,r15
  36:   26 4f           lds.l   @r15+,pr
  38:   f6 6e           mov.l   @r15+,r14
  3a:   0b 00           rts     
  3c:   09 00           nop     
  3e:   09 00           nop     
  40:   00 00           .word 0x0000
        ...
----------

Regards,
Mark Jonas


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