On 5 July 2011 15:49, Dave Martin dave.martin@linaro.org wrote:
On Fri, Jul 1, 2011 at 6:10 PM, David Gilbert david.gilbert@linaro.org wrote:
Hi All, I've just submitted the patches for the 64 bit atomic stuff to the gcc-patches list. Richard Henderson has raised the question of why the ARM commpage isn't a full VDSO and, if it was, then it would make the version number check a lot simpler.
What's the history behind this/how big a job is it/
I think it's there partly for historical reasons, and partly because there has to be a page mapped somewhere for the exception vectors anyway, so we may as well put other snippets of required userspace code there.
OK.
Dave (on holiday for a week but checking mail intermittently)
Because existing userspace source and binaries already call directly into the helper functions in the vectors page, we can't easily remove/move it.
We could possibly wrap the vectors page to make it look like a DSO in a forwards-compatible way, but since this has not happened so far it feels like people never saw much benefit.
Any idea how big a job that is?
Can you describe the benefits with regard to this case? (And, out of interest, how do statically-linked programs make use of needed functionality in the VDSO? Browsing the web hasn't revealed any coherent answers to that question for me...)
Richard's question to my patch is here:
http://old.nabble.com/-Patch-0-3--ARM-64-bit-atomic-operations-tp31974816p31...
My patch is having to test an arbitrary address in the commpage in init code to see if it's new enough to have the new helper that Nicolas just added; Richard's argument is that if it was actually a VDSO I'd just have linked against a symbol and if the symbol wasn't there then I would have got a fairly normal linker error - I wouldn't have needed any special code; and to be honest I think that would also solve the problem that accessing that wacky address is also a pain for things like qemu because we're going to have to intercept that read.
(I've added Richard to the cc).
Dave