[PATCH] ARM and Thumb Segmented Stacks

[Svetoslav Neykov]

So the solution is to implement the alternatives on a per-need basis
and pass the offset at compile time? When no specific 
implementation is selected have "__stack_limit" as the default.
Or have every alternative platform provide its own optimization
pass (possibly as dynamic library if technically possible) which 
converts the __stack_limit call  to whatever it needs?

Regards,
Svetoslav.


-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: Monday, March 03, 2014 1:56 PM
To: Svetoslav Neykov
Cc: llvm-commits
Subject: Re: [PATCH] ARM and Thumb Segmented Stacks

> So for major platforms it can be hardcoded in the source. And niche
> platforms should use the runtime call. Can there be a middle ground?
> For example having a list of available conventions which can be
> selected at compile time - much like the floating point soft vs hard case?

That's not impossible, but seems like a lot of work and code for
something that it's quite possible nobody actually wants to use, and
is certainly niche even if they do. Off the top of my head, the
obvious choices that might make some kind of sense are:
+ MRC for TP (+ arbitrary offset)
+ Fixed TP register (+ arbitrary offset)
+ Load some symbol (+ arbitrary offset)
+ Load arbitrary fixed address (+ arbitrary offset)
+ Call a __stack_limit function (embedded guys can be crazy-keen on code size).
+ Call __aeabi_read_fp (+ arbitrary offset)
+ Syscall (+ arbitrary offset)

I'm not saying we'd need to support all of these, but the fact that
we're doing wild mass-guessing about the preferred interface is rather
worrying.

Cheers.

Tim.