tricore gcc/binutils

You can either:

- use the gcc GCC_EXEC_PREFIX environment variable for forcing your gcc to use tricore-as instead of as:

export GCC_EXEC_PREFIX=tricore-

See

- make sure you have a "triccore-as" executable named "as" when you are cross-compiling (or a symbolic link to it), and add the path the this "as" in your PATH environment variable, so that your compiler will find it before your native "as":

export PATH=/opt/tricore/bin:$PATH

Hope this help,

Jean Tabel

right

"tricore-as".

I thought about that as well...but it will fail on packages requiring host and target gcc/as/ld at the same time...

In which file in gcc the EXEC-PREFIX gets stored along with the pathnames for "gcc", "as" and "ld" ?

rick

gcc

I don't know about any configuration files containing the prefix. The tricore toolchain should have been compiled using the option

--target=tricore, so that exact names for the various executables could have been hardcoded in the executables themselves.

Best solution in your case may be just to go through the various makefiles of your packages, and to modify the values for CC make variables.

This can be done automatically without modifying the Makefiles if your packages are using "configure" scripts. In this case, just replace

./configure by CC=/opt/tricore/bin/gcc ./configure

Could you give me more information on the packages using both tricore and native gcc you want to build ? This may help me to help you...

Jean Tabel

Hello (o;

THe tricore toolchain was configured with "target=tricore-elf"...though the company who has done that called "High-Tec" in Germany has f**ked up it badly (o; There are other errors during compile time like not finding libiconv even if you specifiy it when configuring...

Anyway (o;

Certain packages which require are for example uClinux and u-boot which use host compiler in the beginning (for tkconfig as an example).

Does gcc has a switch to show the compiled in EXEC-PREFIX? Or any other useful information?

best regards rick

Try

the-prefix-gcc -dumpspecs

substituting the proper prefix for the-prefix (e.g. arm-elf-gcc).

It dumps the configuration specifications in GCC internal format which is not too easy to read but it contains the specifications.

HTH

Looks better now...

I made links from individual "/usr/local/tricore/bin/tricore-xxx" to "/usr/local/tricore/bin/xxx"...

So only complaining now about missing libc (o;

iMac:~/develop/tricore jedi$ tricore-gcc main.c /usr/local/tricore/lib/gcc-lib/tricore//../../../../tricore/bin/ld: cannot find -lc

rick

You may try to specify the path for libc by using the -L option: tricore-gcc -L/usr/local/tricore/lib -o main main.c

I know that one...have to compile glibc first for tricore... but there I'm stuck again with this crippled tricore port:

../sysdeps/tricore/dl-machine.h: In function `elf_machine_load_address': ../sysdeps/tricore/dl-machine.h:57: error: [11705] parse error before "movh" ../sysdeps/tricore/dl-machine.h:57:28: invalid suffix "b" on integer constant ../sysdeps/tricore/dl-machine.h:58:28: invalid suffix "b" on integer constant ../sysdeps/tricore/dl-machine.h:59:36: invalid suffix "b" on integer constant ../sysdeps/tricore/dl-machine.h:60:36: invalid suffix "b" on integer constant ../sysdeps/tricore/dl-machine.h:62:29: missing terminating " character

Anything wrong with the inline assembly code in it?

/* Return the run-time load address of the shared object. */ static inline Elf32_Addr __attribute__ ((unused)) elf_machine_load_address (void) { void *tmp, *address; asm("0: movh.a %0, hi:0b lea %0, [%0]lo:0b addih.a %1, %%a12,gotoffhi:0b lea %1, [%1] gotofflo:0b sub.a %0, %1, %0 " : "=a"(address), "=a"(tmp));

return (Elf32_Addr)address; } /* ok: 2003.7.2 */

Never used any inline asm stuff in gcc before (o;

best regards rick

I downloaded the tricore toolchain, and got the same error message when attempting to compile your code after having included ELFTypes.h in oder to get a definition for Elf32_Addr.

It seems the reason is that new versions of gcc don't support multi-line string literals anymore - you should use string concatenation instead: see

The following code compiled properly:

#include

static inline Elf32_Addr __attribute__ ((unused)) elf_machine_load_address (void) { void *tmp, *address; asm("0:" "movh.a %0, hi:0b" "lea %0, [%0]lo:0b" "addih.a %1, %%a12,gotoffhi:0b" "lea %1, [%1] gotofflo:0b" "sub.a %0, %1, %0" : "=a"(address), "=a"(tmp));

return (Elf32_Addr)address; } /* ok: 2003.7.2 */

I don't know of an option that may force the new preprocessor to behave the same way the old did, but you should investigate further.

An other obvious solution would be to look for a version of the kernel or glibc which is not using this deprecated construct.

Hope this help, Jean Tabel

Hmm..where did you download the toolchain?

Was only able to find a patch against GNU sources..

rick

Thanx (o;

Best way is add a '\n' at the end of every assembly line.. that fixes it...

Now where is the missing "crtbegin.o" and "crtend.o"... seems it is missing in the toolchain..only crt0.o there...

rick

Well..this is stupid windows binary evaluation version (o;

I was talking about GNU gcc/binutils sources (o;

rick