[musl] cortex-m support?

[Rob Landley]

I have access to a cortex-M board this week (and maybe next), and would
like to test out musl on it. It's a "SmartFusion 2" running one of the
https://github.com/emcraftsystems kernel trees (I forget which), and
buildroot with uclibc-ng. (In _theory_ that kernel includes fdpic
support, but the uclibc toolchain buildroot builds is binflt.)

There's an ellcc blog entry at http://ellcc.org/blog/?p=23234 that says
he added cortex-m support, which was commit
http://ellcc.org/viewvc/svn?view=revision&revision=4920 in their repo
(ancient patch attached, applies to a ~2 year old musl version).

Some of those changes don't seem to be needed anymore, because the arm
code has been moved to "unified syntax". But when I try to build with
buildroot's cortex-m3 toolchain, it clearly still needs some other changes:

src/setjmp/arm/longjmp.s: Assembler messages:
src/setjmp/arm/longjmp.s:10: Error: thumb conditional instruction should
be in IT block -- `moveq r0,#1'
src/setjmp/arm/longjmp.s:11: Error: SP not allowed in register list --
`ldmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}'

FYI gcc -v says that toolchain is configured with (among other things):

./configure --enable-static --target=arm-buildroot-uclinux-uclibcgnueabi
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-libquadmath --disable-libsanitizer --disable-tls
--disable-libmudflap --enable-threads --without-isl --without-cloog
--with-float=soft --disable-decimal-float --with-abi=aapcs-linux
--with-cpu=cortex-m3 --with-float=soft --with-mode=thumb
--enable-languages=c,c++ --disable-shared --disable-libgomp

(I can dig up the buildroot config if you want to try to reproduce it,
but I think I told Rich about it months ago.)

I have a todo item to try to get QEMU running a cortex-m3 Linux, but
unfortunately last time I checked QEMU's only actual cortex-m3 board
implementation was a toy ("netduino") with 128k of sram. It looks like
the vanilla kernel has 4 cortex-m defconfigs now. (Mostly cortex-m4, but
it seems like that's just funky DSP extensions the kernel presumably
doesn't use; cortex-m3 shipped in 2004 and is the common case nommu
baseline here).

Anyway, is there any interest in this? (Lemme rephrase that: the
_industry_ is screaming for this, is there any interest on the part of
musl?) I can try to hack something together from the old patch if so.
(Or somebody who knows the arm instruction set better can do more than
just "make the compile errors go away" :)

Rob

P.S. Anybody else boggle at the way wikipedia[citation needed]'s
cortex-m page doesn't actually include the phrase "mmu" or "memory
management unit"? No really: https://en.wikipedia.org/wiki/ARM_Cortex-M

[Szabolcs Nagy]

Post by Rob Landley
Anyway, is there any interest in this? (Lemme rephrase that: the
_industry_ is screaming for this, is there any interest on the part of
musl?) I can try to hack something together from the old patch if so.
(Or somebody who knows the arm instruction set better can do more than
just "make the compile errors go away" :)

i think musl is interested in the asm fixes.

fdpic arm is interesting too but it would be better
if there was an abi spec (so there is no toolchain
compatibility issue).

i'm not sure if linux on cortex-m is really what the
industry wants.. i'd assume more cortex-m users would
want musl on baremetal or on custom rtos.

[Szabolcs Nagy]

Post by Szabolcs Nagy
fdpic arm is interesting too but it would be better
if there was an abi spec (so there is no toolchain
compatibility issue).

ok it seems somebody wrote this:
https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt

it's just not upstreamed anywhere (and not specified by the vendor)

[Rob Landley]

Post by Szabolcs Nagy

Post by Szabolcs Nagy
fdpic arm is interesting too but it would be better
if there was an abi spec (so there is no toolchain
compatibility issue).

https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
it's just not upstreamed anywhere (and not specified by the vendor)

Ah, that's one of the three authors of this:

http://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores

Although emcraft.com (the company whose full-time business has been
"Linux on Cortex-M" for over 5 years) is in Moscow. Their fdpic support
patch in their kernel is:

https://github.com/EmcraftSystems/linux-emcraft/commit/673205bf926b

And it looks like it was a port of the work of those guys.

Not sure where you get the relevant gcc patch...

Rob

[Rich Felker]

Post by Rob Landley

Post by Szabolcs Nagy

Post by Szabolcs Nagy
fdpic arm is interesting too but it would be better
if there was an abi spec (so there is no toolchain
compatibility issue).

https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
it's just not upstreamed anywhere (and not specified by the vendor)

http://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores
Although emcraft.com (the company whose full-time business has been
"Linux on Cortex-M" for over 5 years) is in Moscow. Their fdpic support
https://github.com/EmcraftSystems/linux-emcraft/commit/673205bf926b
And it looks like it was a port of the work of those guys.
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so) and the authors probably don't have
copyright assignments taken care of. It would be really nice if
someone could coordinate working with the authors and companies
involved and getting all of that taken care of -- preferably someone
getting paid to do so, since it's not particularly fun work to be
doing as a volunteer.

Rich

[Rob Landley]

Post by Rich Felker

Post by Rob Landley
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so)

https://github.com/mickael-guene/gcc has a 5.2 branch and "master"
updated 20 hours ago, although I'm not sure how much of master updating
is an automatic tracking branch and how much is the account owner
updating things.

Post by Rich Felker
and the authors probably don't have
copyright assignments taken care of.

Nobody does copyright assignments voluntarily. In the long run those
kill projects.

Post by Rich Felker
It would be really nice if
someone could coordinate working with the authors and companies
involved and getting all of that taken care of -- preferably someone
getting paid to do so, since it's not particularly fun work to be
doing as a volunteer.

Github says https://github.com/mickael-guene was last active November
30th (commiting stuff to his cortex-m simulator fork), so he's still
around...

I'm tempted to try to shoehorn the gcc and binutils here into
musl-cross-make and see what happens. But I've already _got_ a cortex-m
targeted toolchain that... can't build musl. Because of the assembly
stuff. So I should probably poke at that first.

Post by Rich Felker
Rich

Rob

[Rich Felker]

Post by Rob Landley

Post by Rich Felker

Post by Rob Landley
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so)

https://github.com/mickael-guene/gcc has a 5.2 branch and "master"
updated 20 hours ago, although I'm not sure how much of master updating
is an automatic tracking branch and how much is the account owner
updating things.

Excellent! That's new since I last communicated with him.

Post by Rob Landley

Post by Rich Felker
and the authors probably don't have
copyright assignments taken care of.

Nobody does copyright assignments voluntarily. In the long run those
kill projects.

I don't want to start an unrelated GNU-politics thread, but I think
you're mistaken here. Any modification of a GNU package will die out
in the long run without copyright assignment, because nobody can
maintain stuff out-of-tree forever. If it's an individual they'll lose
interest; if it's a company their business interests will change or
they'll get bought out by someone who doesn't care. In my opinion this
is 100% the FSF's fault for creating such a broken system, but it's
the reality. So people who modify GNU stuff and who do want their work
to live on and be useful in the future really should be pushing to get
their employers' to authorize the assignments.

Post by Rob Landley

Post by Rich Felker
It would be really nice if
someone could coordinate working with the authors and companies
involved and getting all of that taken care of -- preferably someone
getting paid to do so, since it's not particularly fun work to be
doing as a volunteer.

Github says https://github.com/mickael-guene was last active November
30th (commiting stuff to his cortex-m simulator fork), so he's still
around...
I'm tempted to try to shoehorn the gcc and binutils here into
musl-cross-make and see what happens. But I've already _got_ a cortex-m
targeted toolchain that... can't build musl. Because of the assembly
stuff. So I should probably poke at that first.

This is really good news -- I think adding the patches should be easy.
You can probably just diff his tree against stock 5.2.0 and make it
one big combined patch. This makes getting stuff ready on the musl
side a lot more attractive to me, so I will try to get back to is
asap.

Rich

[Rob Landley]

Post by Rich Felker

Post by Rob Landley

Post by Rich Felker

Post by Rob Landley
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so)

https://github.com/mickael-guene/gcc has a 5.2 branch and "master"
updated 20 hours ago, although I'm not sure how much of master updating
is an automatic tracking branch and how much is the account owner
updating things.

Excellent! That's new since I last communicated with him.

Post by Rob Landley

Post by Rich Felker
and the authors probably don't have
copyright assignments taken care of.

Nobody does copyright assignments voluntarily. In the long run those
kill projects.

I don't want to start an unrelated GNU-politics thread, but...
...
In my opinion this is 100% the FSF's fault for creating such a broken
system, but it's the reality.

More or less what I meant, yes.

Keep in mind gcc development -already_ died once (egcs), and the lesson
the llvm guys learned is "don't fork off the old dead base, even if it's
been dead for years it's poison and they'll steal it back if you get it
going again, instead start over from scratch with something they have no
claim to".

Post by Rich Felker
So people who modify GNU stuff and who do want their work
to live on and be useful in the future

already screwed up before the "and"; everything else is damage control.

Post by Rich Felker
This is really good news -- I think adding the patches should be easy.
You can probably just diff his tree against stock 5.2.0 and make it
one big combined patch. This makes getting stuff ready on the musl
side a lot more attractive to me, so I will try to get back to is
asap.

FYI, the cortex-m toolchain I've been building (which builds a kernel
and userspace that runs on the board) is just buildroot's cortex-m
toolchain.

Grab current buildroot, "make defconfig" then "make menuconfig" and:

target options -> target architecture -> arm little endian
target options -> target architecture variant -> cortex-m3
build options -> host dir (set to /opt/arm-linux)
toolchain->enable c++ support

Then "sudo make" (so it can write to /opt/arm-linux).

The version of buildroot I had needed to do "ln -s arm-linux-ld.real
/opt/arm-linux/usr/bin/ld.real" because the binflt wrapper is broken and
evil, but maybe that's fixed upstream since? And the buildroot commit
history disables -Os on cortex-m due to some compiler bug (maybe fixed
now? Haven't hit it myself but I build with -O2 instead for this board
on general principles.)

Oh, and there's a separate "Enable elf2flt support" config thing in the
toolchain menu that you DON'T want to select or it'll wrap the toolchain
_twice_ and break, buildroot does it automatically for cortex-m. I think
it's even a magic wrapper doing the -Wl,-elf2flt stuff automatically. :)

Post by Rich Felker
Rich
.

Rob

[Rob Landley]

Post by Rich Felker

Post by Rob Landley

Post by Rich Felker

Post by Rob Landley
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so)

https://github.com/mickael-guene/gcc has a 5.2 branch and "master"
updated 20 hours ago, although I'm not sure how much of master updating
is an automatic tracking branch and how much is the account owner
updating things.

Excellent! That's new since I last communicated with him.

In theory, what you do is follow the instructions in:

https://github.com/mickael-guene/fdpic_manifest

Which uses repo to download the github repositories, and then has a
build.sh. In practice, I'm not sure what branches that uses to build
said toolchain.

However, this would give you a uClibc-based cortex-m-fdpic toolchain you
could then swap musl into. It also has a lsit of kernel patches that
theoretically work against vanilla, but you don't have a board for that. :)

I did poke you over the summer about running cortex-m binflt binaries
under qemu application emulation (works fine). I dunno if it supports
the fdpic loader or not, building this toolchain to find out. If not,
it's got an emulator there too but I haven't poked at it yet...

Rob

[Rich Felker]

Post by Rob Landley

Post by Rich Felker

Post by Rob Landley

Post by Rich Felker

Post by Rob Landley
Not sure where you get the relevant gcc patch...

I have links to the repos somewhere; the problem is that they're
forked from a fairly old gcc version (although not nearly as bad as
sh-fdpic; I think it's 4.8 or so)

https://github.com/mickael-guene/gcc has a 5.2 branch and "master"
updated 20 hours ago, although I'm not sure how much of master updating
is an automatic tracking branch and how much is the account owner
updating things.

Excellent! That's new since I last communicated with him.

https://github.com/mickael-guene/fdpic_manifest

OK, I'll take a look.

Post by Rob Landley
Which uses repo to download the github repositories, and then has a
build.sh. In practice, I'm not sure what branches that uses to build
said toolchain.
However, this would give you a uClibc-based cortex-m-fdpic toolchain you
could then swap musl into.

Just diffing the tree and dropping the patch in musl-cross-make is
going to be a much faster path to getting something reproducible and
testable.

Post by Rob Landley
It also has a lsit of kernel patches that
theoretically work against vanilla, but you don't have a board for that. :)

Can you get me (instructions for building) a kernel that boots on qemu
but has the fdpic-support patches for arm? The main patch hunk that'll
be needed is the part in signal handler invocation that uses the
function pointer as either a code address or a function descriptor.

BTW, upstreaming this patch without an old pending kernel change I
still need to submit will introduce a CVE-worthy vulnerability on all
ARM systems. :-)

Post by Rob Landley
I did poke you over the summer about running cortex-m binflt binaries
under qemu application emulation (works fine). I dunno if it supports
the fdpic loader or not, building this toolchain to find out. If not,
it's got an emulator there too but I haven't poked at it yet...

It can load fdpic as normal ELF just fine, but signal handlers will
crash if it doesn't treat the application-passed function pointer as a
function descriptor. Fixing this should just be a several-line patch
to qemu if nobody already did it.

Rich

[Rob Landley]

Post by Szabolcs Nagy
i'm not sure if linux on cortex-m is really what the
industry wants..

http://electronicdesign.com/embedded/practical-advice-running-uclinux-cortex-m3m4
https://community.arm.com/thread/5364
http://events.linuxfoundation.org/sites/events/files/slides/optimize-uclinux.pdf
http://www.microsemi.com/document-portal/doc_download/130852-linux-cortex-m-user
http://stackoverflow.com/questions/6636830/how-do-i-run-linux-on-an-arm-cortex-m3-board
http://hackerboards.com/iot-dev-kit-runs-uclinux-on-a-microsemi-cortex-m3-fpga-soc/
http://www.cnx-software.com/2014/06/28/amptek-icon-is-an-arm-cortex-m3-board-for-iot-running-uclinux-crowdfunding/
http://electronics.stackexchange.com/questions/19234/linux-on-arm-cortex-m3-series
http://elinux.org/STM32
http://www.cnx-software.com/2011/12/30/linux-for-cortex-m3-m4-microcontrollers/
https://angel.co/projects/137810-design-of-an-arm-cortex-m4-stm32f4-based-embedded-linux-system?src=user_profile
https://falstaff.agner.ch/2015/05/17/u-boot-command-to-boot-vybrids-cortex-m4-core/
https://developer.mbed.org/users/noritsuna/notebook/linux-on-cortexm3armv7m/

It's a mystery,

Rob

[Rich Felker]

Added support for the Cortex-M.
------------------------------------------------------------------------
Index: src/internal/arm/syscall.s
===================================================================
--- src/internal/arm/syscall.s (revision 4919)
+++ src/internal/arm/syscall.s (revision 4920)
@@ -11,5 +11,6 @@
svc 0
ldmfd sp!,{r4,r5,r6,r7}
tst lr,#1
+ it eq
moveq pc,lr
bx lr

There's a gas option -Wa,-mimplicit-it=always that will make these
kind of changes unnecessary. I think it's preferable to just have
musl's configure always add that option when targeting arm if it's
accepted by the toolchain. Otherwise new code might get added without
checking that it builds as thumb.

Index: src/setjmp/arm/setjmp.S
===================================================================
--- src/setjmp/arm/setjmp.S (revision 0)
+++ src/setjmp/arm/setjmp.S (revision 4920)
@@ -0,0 +1,45 @@
+.global __setjmp
+.global _setjmp
+.global setjmp
+.type __setjmp,%function
+.type _setjmp,%function
+.type setjmp,%function
+ mov ip,r0
+#if defined(__thumb__)
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,lr}
+ str sp, [ip], #4
+#else
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
+#endif

My leaning is to just always use the version that works on thumb, as I
don't think the performance difference will be measurable. I think you
did change the order of the storage in jmp_buf; I'm okay with that but
we might want to see if anyone objects because of wacky stuff
expecting a particular order. (Note: I don't think the order should be
treated as public but we probably want to know what if anything is
poking at it so we know if there are third-party things that need
fixing.)

Index: src/thread/arm/clone.s
===================================================================
--- src/thread/arm/clone.s (revision 4919)
+++ src/thread/arm/clone.s (revision 4920)
@@ -16,6 +16,7 @@
beq 1f
ldmfd sp!,{r4,r5,r6,r7}
tst lr,#1
+ it eq
moveq pc,lr
bx lr

Clone will also need a fix something like what I did for sh in commit
234c58467c3709bafdd3ffa6ac73655e1dfd9ddb to be compatible with fdpic,
but that's separate from thumb support.

Index: Makefile
===================================================================
--- Makefile (revision 4919)
+++ Makefile (revision 4920)
@@ -106,6 +106,10 @@
$(dir $(patsubst %/,%,$(dir $(1))))$(notdir $(1:.s=.o)): $(1)
endef
$(foreach s,$(wildcard src/*/$(ARCH)*/*.s),$(eval $(call mkasmdep,$(s))))
+define mkasmdepS
+$(dir $(patsubst %/,%,$(dir $(1))))$(notdir $(1:.S=.o)): $(1)
+endef
+$(foreach s,$(wildcard src/*/$(ARCH)*/*.S),$(eval $(call mkasmdepS,$(s))))
%.o: $(ARCH)$(ASMSUBARCH)/%.sub
@@ -113,6 +117,9 @@
%.o: $(ARCH)/%.s
+%.o: $(ARCH)/%.S
+
%.o: %.c $(GENH) $(IMPH)
@@ -122,6 +129,9 @@
%.lo: $(ARCH)/%.s
+%.lo: $(ARCH)/%.S
+
%.lo: %.c $(GENH) $(IMPH)

This looks like it's against a really old version of musl. The modern
build system with out-of-tree support already accepts .S files.

Index: arch/arm/src/arm/atomics.s
===================================================================
--- arch/arm/src/arm/atomics.s (revision 4919)
+++ arch/arm/src/arm/atomics.s (revision 4920)
@@ -6,12 +6,13 @@
ldr ip,1f
ldr ip,[pc,ip]
- add pc,pc,ip
+ add pc,ip

I don't think this actually works; the arithmetic on pc does different
things in thumb mode. This file just needs to be scrapped and
redesigned since it's not going to be compatible with fdpic anyway (it
relies on PC-relative accesses to global data).

Index: arch/arm/crt_arch.h
===================================================================
--- arch/arm/crt_arch.h (revision 4919)
+++ arch/arm/crt_arch.h (revision 4920)
@@ -1,11 +1,17 @@
-__asm__("\
-.text \n\
-.global _start \n\
-.type _start,%function \n\
-_start: \n\
- mov fp, #0 \n\
- mov lr, #0 \n\
- mov a1, sp \n\
- bic sp, sp, #0xF \n\
- bl __cstart \n\
-");
+__asm__(
+".text \n"
+".global _start \n"
+".type _start,%function \n"
+"_start: \n"
+" mov fp, #0 \n"
+" mov lr, #0 \n"
+" mov a1, sp \n"
+#if defined(__thumb__)
+" mov a2, sp \n"
+" bic a2, #0xF \n"
+" mov sp, a2 \n"
+#else
+" bic sp, sp, #0xF \n"
+#endif
+" bl __cstart \n"
+);

I think I had a simpler version of this tucked away somewhere; I'll
check and see.

Thanks for working on this and reviving interest in the topic.

Rich

[Rich Felker]

Post by Rich Felker

Added support for the Cortex-M.
------------------------------------------------------------------------
Index: src/internal/arm/syscall.s
===================================================================
--- src/internal/arm/syscall.s (revision 4919)
+++ src/internal/arm/syscall.s (revision 4920)
@@ -11,5 +11,6 @@
svc 0
ldmfd sp!,{r4,r5,r6,r7}
tst lr,#1
+ it eq
moveq pc,lr
bx lr

There's a gas option -Wa,-mimplicit-it=always that will make these
kind of changes unnecessary. I think it's preferable to just have
musl's configure always add that option when targeting arm if it's
accepted by the toolchain. Otherwise new code might get added without
checking that it builds as thumb.

I dug up the changes I made to get it to build (not run; atomics.s is
broken) as thumb-only; see attached. Note that the atomics.s part of
the diff actively breaks the code so that it won't work even as arm
code.

I'll see if I can come up with a good solution for the atomics. One
thing I do need to know is how the thread pointer is supposed to be
read on cortex-m, since afaik the coprocessor register normally used
does not exist. Does the kernel trap and emulate the coprocessor
register, or is there some other mechanism that must be used?

Rich

[Rob Landley]

Post by Rich Felker

Index: src/setjmp/arm/setjmp.S
===================================================================
--- src/setjmp/arm/setjmp.S (revision 0)
+++ src/setjmp/arm/setjmp.S (revision 4920)
@@ -0,0 +1,45 @@
+.global __setjmp
+.global _setjmp
+.global setjmp
+.type __setjmp,%function
+.type _setjmp,%function
+.type setjmp,%function
+ mov ip,r0
+#if defined(__thumb__)
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,lr}
+ str sp, [ip], #4
+#else
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
+#endif

My leaning is to just always use the version that works on thumb,

Presumaby there's a longjmp.S bit too because:

ldmia ip!, {v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}

Make sure you're aware of erratum 752419:

https://sourceware.org/ml/binutils/2011-05/msg00087.html

On a board with a lot of serial traffic, it takes about 3 minutes for
uClibc (yes, including the current -ng) to crash (by loading the link
register into the stack pointer and stomping code before the setjmp).

The emcraft guys fixed this in their cortex-m uClibc fork way back when
(http://www.emcraft.com/som/building-uclibc), and of _course_ never
bothered to send it upstream. (Or put it on github with their kernel and
uboot.) But the source is in their distro tarball, and their patch to
uClibc's __longjmp.S is basically:

--- uclibc-1.0.17/libc/sysdeps/linux/arm/__longjmp.S
+++ emcraft/libc/sysdeps/linux/arm/__longjmp.S
@@ -56,9 +60,15 @@
#if defined(__thumb2__)
/* Thumb-2 does not allow loading sp with ldm. */
ldmia ip!, {v1-v6, sl, fp}
+#if 0
ldr sp, [ip], #4
ldr lr, [ip], #4
#else
+ ldr sp, [ip, #0]
+ ldr lr, [ip, #4]
+ add ip, #8
+#endif
+#else
ldmia ip!, {v1-v6, sl, fp, sp, lr}
#endif


(Dunno why the "add ip, #8" because it's a scratch register and this is
the last use in the function, but maybe they just made it do exactly
what the #else case does?)

cc-ing buildroot because this is still broken in their november release.

Rob

[Waldemar Brodkorb]

Hi,
Rob Landley wrote,

Post by Rob Landley

Post by Rich Felker

Index: src/setjmp/arm/setjmp.S
===================================================================
--- src/setjmp/arm/setjmp.S (revision 0)
+++ src/setjmp/arm/setjmp.S (revision 4920)
@@ -0,0 +1,45 @@
+.global __setjmp
+.global _setjmp
+.global setjmp
+.type __setjmp,%function
+.type _setjmp,%function
+.type setjmp,%function
+ mov ip,r0
+#if defined(__thumb__)
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,lr}
+ str sp, [ip], #4
+#else
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
+#endif

My leaning is to just always use the version that works on thumb,

ldmia ip!, {v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
https://sourceware.org/ml/binutils/2011-05/msg00087.html
On a board with a lot of serial traffic, it takes about 3 minutes for
uClibc (yes, including the current -ng) to crash (by loading the link
register into the stack pointer and stomping code before the setjmp).
The emcraft guys fixed this in their cortex-m uClibc fork way back when
(http://www.emcraft.com/som/building-uclibc), and of _course_ never
bothered to send it upstream. (Or put it on github with their kernel and
uboot.) But the source is in their distro tarball, and their patch to
--- uclibc-1.0.17/libc/sysdeps/linux/arm/__longjmp.S
+++ emcraft/libc/sysdeps/linux/arm/__longjmp.S
@@ -56,9 +60,15 @@
#if defined(__thumb2__)
/* Thumb-2 does not allow loading sp with ldm. */
ldmia ip!, {v1-v6, sl, fp}
+#if 0
ldr sp, [ip], #4
ldr lr, [ip], #4
#else
+ ldr sp, [ip, #0]
+ ldr lr, [ip, #4]
+ add ip, #8
+#endif
+#else
ldmia ip!, {v1-v6, sl, fp, sp, lr}
#endif
(Dunno why the "add ip, #8" because it's a scratch register and this is
the last use in the function, but maybe they just made it do exactly
what the #else case does?)
cc-ing buildroot because this is still broken in their november release.

I am wondering why you don't cc me or any uclibc related list?

You still believe uClibc projects should die?

It is really cool and very nice that the communication between Rich
and me is always fruitful. I always report any bugs I find while
testing musl on new or old platforms (mostly via IRC channel) and I
always take care that bugfixes for musl targets end up in buildroot.
(mipsr6 support, binutils microblaze problems, ..)

I really would like to see a similar open communication between the
nommu community, you and me.

Just ignoring uClibc-ng does not will make it die.

As a good starting point, a nice bug report and/or test application
which allows me to reproduce the problem would be really
appreciated.

best regards
Waldemar

[Rob Landley]

Hi Rob,
Rob Landley wrote,

I missed this the first time because gmail is crap. (I wash email
through it for the spam filtering, but there's no way to get it to STOP
duplicate killing, so a reply like this gets randomly sorted into the
buildroot folder, the musl folder, or my inbox depending on which copy
arrvied first. Makes following threads impossible, let alone archiving
them. Yes I have complained to Google multiple times over the past few
years, they're too big to hear me.)

So I just noticed it in the musl web archive, but I think it's off topic
here. I assume your list will bounce posts from non-subscribers, so
lemme send my reply to the old uClibc mailing list instead. (*shrug*
Still subscribed there, and you're the only one who posts there, so...)

Rob

[Rich Felker]

Post by Rob Landley

Post by Rich Felker

Index: src/setjmp/arm/setjmp.S
===================================================================
--- src/setjmp/arm/setjmp.S (revision 0)
+++ src/setjmp/arm/setjmp.S (revision 4920)
@@ -0,0 +1,45 @@
+.global __setjmp
+.global _setjmp
+.global setjmp
+.type __setjmp,%function
+.type _setjmp,%function
+.type setjmp,%function
+ mov ip,r0
+#if defined(__thumb__)
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,lr}
+ str sp, [ip], #4
+#else
+ stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
+#endif

My leaning is to just always use the version that works on thumb,

ldmia ip!, {v1,v2,v3,v4,v5,v6,sl,fp,sp,lr}
https://sourceware.org/ml/binutils/2011-05/msg00087.html

Thanks. I wasn't aware of this. But my proposed version of the patch
is already immune; it doesn't use ldr to sp, but instead ldm to a temp
register followed by mov to sp. I grepped for ldr to sp and did not
find any instances that are incrementing forms.

Rich