Re: SuperH conflict of arch/sh/__set_thread_area vs thread/__set_thread_area

[Christian Lamparter <chunkeey@googlemail.com>]

On Wednesday, August 19, 2015 11:04:02 PM Rich Felker wrote:
> On Thu, Aug 20, 2015 at 02:44:11AM +0200, Christian Lamparter wrote:
> > Hello,
> > 
> > I'm trying to add a port for a SH4-like ARCH to OpenWRT, which uses the latest
> > musl-1.1.10 as the default libc. I'm having the following problem when building
> > the toolchain:
> > 
> > During the final linker-step, the symbol "__set_thread_area"  declared twice.
> > This is because the SH architecture provides a separate __set_thread_area [0],
> > (other archs use the standard syscall wrapper from [1]).
> > 
> > Obviously, I want this issue fixed. However I'm new to SuperH and musl, that's
> > why I need advise :-D. For now, I defined the src/thread/__set_thread_area as
> > a weak symbol. Now, that's just a crude hack, what would be better solution?
> > (I can make and post the patch if necessary - But sadly, I can't test it on the
> > hardware yet)?
> 
> Bobby Bingham's reply explains what the issue is. Did you make a new
> arch name rather than using the existing sh arch for your port? 
Initially, yes I did. I had the ARCH at "sh4". This was because OpenWRT 
already had infrastructure for some sh-(sub)targets (sh3, sh3eb, sh4, sh4eb)
in place. But they seem to be unused and untested. The only target which has
support for SuperH is UserModeLinux. However, it will probably run into the
same issue.

Now, I've changed ARCH to "sh" and set the CPU_TYPE to sh4 [toolchain
dir changed to toolchain-sh_sh4_gcc-5.2.0_musl-1.1.10]. But still no 
luck, the original error code remains the same.

src/thread/__set_thread_area.lo: In function `__set_thread_area':
__set_thread_area.c:(.text+0x0): multiple definition of `__set_thread_area'
arch/sh/src/__set_thread_area.lo:__set_thread_area.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:142: recipe for target 'lib/libc.so' failed

> If it's ABI-compatible, it would probably make more sense to use the
> existing one and extend it to support your hardware.
In case you want to know: Hardware is a 2013 Sat>IP set-top-box
(idl4k platform) with a STx7108 (that's sh4, little endian, 
with mmu and with fpu).

> I'm working on an sh-related project right now 
> (see http://0pf.org/j-core.html) and one of my goals is to get sh
> more unified as a platform where it's possible to have binaries
> for the baseline ISA that work on lots of different hardware models
> (including nommu ones).
The J4 arch is sadly 2 years ahead of time ;-) [EU4]. But I think
I'll definitely need some help to figure out - Another issue seems
to be that the arch string changed from sh*-linux to sh-*-linux
between gcc-4.8 and gcc-5.2... So, what to do?

Regards,
Christian