This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
AW: Renesas __trap34() system calls broken - possibly on other platforms, too
- From: "Jonas Mark (ST-FIR/ENG1)" <Mark dot Jonas at de dot bosch dot com>
- To: "Dave Korn" <dave dot korn at artimi dot com>, "Andrew STUBBS" <andrew dot stubbs at st dot com>, <newlib at sourceware dot org>
- Date: Wed, 10 Jan 2007 10:59:21 +0100
- Subject: 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