mips32r2_common: Update thread_arch for compatibility with newer toolchains

[jnohlgard]

Contribution description

This should fix the build issue described in RIOT-OS/riotdocker#47

Testing procedure

Install a new version of the mips-mti-elf toolchain, or use the proposed Docker image in RIOT-OS/riotdocker#47
Run some test applications on actual hardware (e.g. pic32-clicker or pic32-wifire)

Issues/PRs references

RIOT-OS/riotdocker#47

[cladmi]

On ubuntu 16.04 it fixes the first issue with the new mips toolchain but I have the new following one with pic32-wifire at least (the one I have to test):

objcopy: RIOT/examples/hello-world/bin/pic32-wifire/hello-world.hex: address 0xffffffff1d000000 out of range for Intel Hex file

I will try with the updated docker image as I do not have the issue on arch linux.

[jnohlgard]

I get that error too on my machine, but not in the docker image.

[cladmi]

It's strange because the objcopy version is the same…

[jnohlgard]

@cladmi did you test with the new Docker image?

[cladmi]

I tried and I think I did not have issues, I should verify tomorrow on the other laptop.
Also wanted to maybe start doing loaded libraries debugging or strace things to find whiy.

However I also still need to test an error path that triggers _mips_handle_exception.

If the code works but we still get the objdump issue, it could still go in I think as it does not change any behavior on the current mips version, but would just need another round of tests before saying the mips link should be updated now and deployed on murdock.

It's however in my priority list to have a working docker image.

[cladmi]

Maybe put in the header commit message that it is defined in mips/hal.h

[cladmi]

It compiles for all three mips boards with the RIOT-OS/riotdocker#47 docker image

I did not have time to test today, will be on thursday.

[cladmi]

The difference I have between the ubuntu 16.04 and the docker container is the libbfd version used by objcopy.

ubuntu16.04$ ldd $(which objcopy)
        linux-vdso.so.1 =>  (0x00007ffcf1b37000)
        libbfd-2.26.1-multiarch.so => /usr/lib/x86_64-linux-gnu/libbfd-2.26.1-multiarch.so (0x00007f7d6f8dc000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7d6f512000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7d6f2f8000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7d6f0f4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7d6fe3c000)

root@docker_pr47:~# ldd $(which objcopy)                                                                                              
        linux-vdso.so.1 =>  (0x00007fff4535a000)
        libbfd-2.26.1-system.so => /usr/lib/x86_64-linux-gnu/libbfd-2.26.1-system.so (0x00007fb6fb1a3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb6fadd9000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb6fabbf000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb6fa9bb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb6fb4e8000)

If I try running with the non multiarch version it works:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libbfd-2.26.1-system.so objcopy ...

[cladmi]

But it also fails with mips-mti-elf-objcopy so could still be showing an error in a linker script or a new configuration that should be set.

[cladmi]

There is a reference here but not helping much http://forum.pinguino.cc/showthread.php?tid=3267

[cladmi]

It was also already mentioned by @aabadie in RIOT-OS/Release-Specs#44 (comment)

[jnohlgard]

Rebased, added code comment about why we need the macro in the older toolchains.

[benpicco]

I suppose this was superseded by #11986 and can now be closed?

[kaspar030]

I suppose this was superseded by #11986 and can now be closed?

Aaah, I wasn't aware of this. Sorry @gebart!

Yeah, this is obsolete.