On 5 July 2011 15:49, Dave Martin <dave.mar...@linaro.org> wrote: > On Fri, Jul 1, 2011 at 6:10 PM, David Gilbert <david.gilb...@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-tp31974816p31974901.html 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
