Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Aug 2015 16:07:39 +0200
From: Christian Lamparter <>
Cc: Rich Felker <>, Bobby Bingham <>,
Subject: Re: SuperH conflict of arch/sh/__set_thread_area vs thread/__set_thread_area

(Added Openwrt-dev - since this isn't a musl issue)

On Thursday, August 20, 2015 12:21:55 PM Christian Lamparter wrote:
> 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:
> > > 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/' failed

Ok, I have a update and I fixed this issue with __set_thread_area.s.
The reason why this didn't work and was harder to debug than usual is
because of the involvement of the "patch" utility with the -E flag

Openwrt adds a number of patches to the musl-1.1.10.tar.gz [0] (actually
they seem to be cherry-picked from musl git). Now, one of the patches 
"001-git-2015-07-22.patch" contains:

commit f9d84554bae0fa17c9a1d724549c4408022228a5 [1]
Author: Rich Felker <>
Date:   Tue Jun 16 14:28:30 2015 +0000

    add support for sh2 interrupt-masking-based atomics to sh port
This commit reduces the "src/thread/sh/__set_thread_area.s" to an empty
file (but it doesn't remove it). But due to bad luck, the script that
patches the file [2] (it's called, but it's used to patch
the toolchain as well) uses the pesky "-E" flag (line 40):
 [...] ${PATCH:-patch} -f -p1 -E -d ${targetdir} 

==> And that's why the __set_thread_area.s file disappears.

I came up with two possible fixes for OpenWRT, unless you want to
fix this in musl (via non-empty __set_thread_area) instead: 

1. have some content in __set_thread_area.s to prevent it from being


--- a/src/thread/sh/__set_thread_area.s
+++ b/src/thread/sh/__set_thread_area.s
@@ -0,0 +1,1 @@
+/* the patch utility might remove empty files */


2. patch

--- a/scripts/
+++ b/scripts/
@@ -37,7 +37,7 @@ for i in ${patchdir}/${patchpattern} ; do
     [ -d "${i}" ] && echo "Ignoring subdirectory ${i}" && continue	
     echo ""
     echo "Applying ${i} using ${type}: " 
-    ${uncomp} ${i} | ${PATCH:-patch} -f -p1 -E -d ${targetdir} 
+    ${uncomp} ${i} | ${PATCH:-patch} -f -p1 -d ${targetdir}
     if [ $? != 0 ] ; then
         echo "Patch failed!  Please fix $i!"
 	exit 1


Does anyone have any preferences? I'm opting for "patch patch-kernel"
(and I will send a proper patch next week to OpenWRT even if no one
cares now :-D ) 


[0] <>
[1] <>
[2] <>

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.