[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Apr 2016 23:37:58 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: vfork on ARM
On Mon, Apr 04, 2016 at 12:25:00PM +1000, Patrick Oppenlander wrote:
> On 04/04/16 10:14, Rich Felker wrote:
> >>Do you know if v7-m has the hardware TLS registers?
> >...but it lacks the coprocessor register for TLS. However since the
> >instruction to access it is representable in thumb2, the kernel could
> >trap and emulate it. I think the people doing nommu ARM Linux stuff
> >added a syscall for get_tls, but in theory that's just as costly as
> >trap-and-emulate, so I'd rather get trap-and-emulate working so that
> >the same binaries can run on v7-a without runtime selection of the TLS
> >method.
>
> Trap-and-emulate makes perfect sense to me. It's common to fix
> floating point behaviours like this so why not TLS.
>
> Actually, I had a question on this point. I never got to the bottom
> of why ARM uses an architecture specific set_tls syscall rather than
> SYS_set_thread_area like i386 & others. Is this just a historic
> thing?
I think it's just a historical mistake.
> >>Right now I'm working on my own small kernel which will (hopefully)
> >>implement enough of the linux syscall interface to be useful. It's
> >>meant for small embedded microcontrollers where 4MiB of RAM is
> >>considered luxurious.
> >>
> >>It's based on the now abandoned Prex operating system
> >>(http://prex.sourceforge.net/) but is a major fork which goes back
> >>to a traditional monolithic kernel model. I've replaced the C libary
> >>with musl and userspace is currently toybox.
> >>
> >>I'm planning on releasing on github (BSD or no-license) once I can
> >>boot the first targets (arm-mmu and arm-nommu) to a working
> >>userspace and pass some unit tests.
> >>
> >>Maybe once I've learnt enough about how all this stuff works I'll be
> >>able to contribute to other projects like linux/musl.
> >If your intent to run a whole userspace environment on it, or just a
> >single process? If the latter, plain (non-FDPIC) PIE ELF is not a bad
> >solution at all. It precludes XIP from ROM, but at least you don't
> >have repeated per-process overhead from many instances of same
> >executable.
>
> It will be single user, single session, multi process. One long term
> goal is to be self hosting.
>
> Why does PIE preclude XIP? I hoped that it would still be possible
> to XIP a static PIE ELF if the XIP address is known at link time,
> then use a GOT. I haven't thoroughly studied the ABI's here yet and
> may well be barking up the wrong tree.
PIE does not hard-code a load address (the loader can pick the load
address, and could match it to ROM) but the relative offset between
load segments (the read-only text and read-write data) is fixed at
ld-time as usual for ELF. This certainly precludes using the text
in-place if there can be more than once instance executing (since they
can't both have their data at the same offset from text) and makes it
difficult to even run one instance in-place (only possible if you can
arrange for free RAM to exist at the right fixed offset. If you really
wanted to hack up such a setup, you would want non-PIE ELF files where
you pick the absolute addresses for load segments, not PIE where you
can only pick the relative address.
> Worst case scenario I'll just start with relocatable code for nommu
> and work from there.
I'm not sure what you mean by relocatable code here.
> FDPIC is quite a compelling solution. Hopefully this gains some momentum.
Yes, it's the right solution for nommu.
Rich
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.
