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

["Jonas Mark (ST-FIR/ENG1)" <Mark dot Jonas at de dot bosch dot com>]

Hello Andrew,

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

Agreed and accepted as a workaround.

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

No, it is not about hand-coded assembler code. The __trap34()
implementation in trap.S is overwritten during link time by my code.
syscalls.c is C language and my code is as well (see my first post). My
code implements the variadic function __trap34(). Because it only has an
implicit function prototype in syscalls.c the compiler cannot know it is
variadic and therefore rightly does not produce matching code.

Is __trap34() something else but variadic? If yes, what is its
prototype?

> 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, that's what I am looking forward to.

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

I will have a look what they can do for me.

Regards,
Mark Jonas