On Wed, Feb 15, 2012 at 12:09:41AM +0000, Uoti Urpala wrote: > > Anyway, the C standard says that there is a requirement that > > both the DSO itself as all other objects must be able to take > > the address of it and still get the same pointer. And this > > obviously fails in your example. > > Yes, it fails in that example. But if you're trying to imply that this would > mean protected visibility itself must be wrong, that does not follow: instead, > you can say that the tools were invoked with incorrect arguments (missing > -fPIE).
Or that the tools don't implement the needed things to make it work without -fPIE. > > > > As far as I understand things, this is supposed to work, and might > > > > > > It cannot work in the usual setup. Relocations are not supported for the > > > main binary even on platforms that support them for shared libraries. > > > > I'm pretty sure that the main binary supports relocations. Else > > I meant the kind of text relocations that you can use in libraries on i386 but > not on AMD64, and which -fPIC avoids. Which has nothing to do with the executable? > > So I would argue that the linker should either have created > > different relocations or refused to create a binary, since > > it's creating broken code. > > How could the linker create different relocations? I think doing that at link > stage would necessarily require adding relocations for the code of the main > executable. Those certainly aren't supported now, and while I haven't checked > the details, I believe adding support would require changing more than the > linker. And nobody will be interested in implementing it either. > As for refusing to create a binary, that would probably be possible at least > in > the protected-visibility case, as the protected status is visible in the > object > file. OTOH in many cases things could still work, so a warning might be better > than a hard failure (many libraries have no modifiable global variables, and > for > many typical uses having parts of the code see different instances of a > constant > symbol would still work as long as the contents of the instances are equal). I really see no point in exporting constants and then marking them protected. About the only useful exported constant I can think of is something like a version string. And you really want to use a function for that. For all other cases I can't see how it's supposed to work. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120215175318.gb16...@roeckx.be
