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

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Jonas Mark (ST-FIR/ENG1) wrote:
> 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.

You don't need to replace all 27, only the -mrenesas ones (and then only 
really to one you actually use), and even if you did need to replace 
them all it is much less painful than rebuilding the whole library from 
scratch. In fact, you don't even need to modify the library files. you 
can just provide the replacement .o file in your compiler invocation (or 
perhaps via the compiler specs file).

> 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".

So we've established that the problem is solely in the hand-coded 
assembler used to call the traps. On closer inspection it's not actually 
in syscalls.c, but trap.S (newlib/libc/sys/sh), and your quite right, 
there is no mention of the Renesas ABI (at least in the unmodified 
newlib version).

> > > 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.

Except that it's their responsibility to support their own distribution 
(not to mention distributing one that works in the first place). They 
will have modified the version of newlib you have (most likely) so we 
don't even know what you have. Also, the KPIT guys are part of the 
newlib development community and will, no doubt, contribute the fix for 
everybody's use.

> >   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.

You misunderstand what 'crossgcc' is. Perhaps it is a misnomer. CrossGCC 
is concerned with producing gcc-based cross-compilation toolsets, 
including the system library.

Andrew