Garrett D'Amore wrote: > John Plocher wrote: >> On a related note, the upcoming S10->OpenSolaris Enterprise transition >> is *the* time for such a change. If you miss this train, you will not >> have the opportunity to easily do so for quite a while. >> >> While I agree that "mapfile version = 2 means nonexec stacks" is a >> poorly overloaded semantic for such a change, I urge you to come up >> with a usable mechanism and deploy it in this release. >> > > It seems, to me at least, like the time to make this change is now. I > don't think that the syntax ought to be the trigger though. > > New objects built on OpenSolaris ought to use a non-exec stack by > default. Without user intervention. I think executable stacks should > be an opt-in feature. > > The question at hand (IMO), is avoiding breakage for old > binaries/objects which may rely on executable stacks. > > So I guess what I'm talking about is a change in the default, globally. > I presume its possible to do this so the default is applied at compile > time, rather than load time? (That would address the concern of > breakage of older binaries.) > > Btw, I'm of the mind that it may be questionable to retain the old v1 > mapfile syntax for very long. As indicated, not many people are using > it, and we really shouldn't have to carry around baggage ~forever. I > don't think the mapfile syntax was ever officially part of our source > compatibility story. :-) > > Perhaps a tool (script) to automatically convert a v1 mapfile to a v2 > format would be helpful here? > > - Garrett
I agree with the sentiment that executable stacks should be an opt in feature, and not tied to mapfile syntax. If you want to change the world, this is the only comprehensive way to do that, and my guess is that it won't break many programs. I sent mail to some folks in the Solaris group earlier today proposing that, and hopefully something good will come of it. With that, I'd like to suggest that changing the stack protections is not this case. ----- I'd be happy to phase out the V1 syntax, but we really have no way of knowing who is using it, or how. I've chosen to be conservative on this, and provide a bridge. I spent years as an ISV, and I know that they don't appreciate having to revisit working systems, even for good reasons. I don't want to give anyone an excuse not to stay with Solaris over something as minor as this. The win of the v2 syntax isn't going to be big for these folks anyway --- I would not be proposing a new syntax if symbol versioning was the sole concern. There's not much cost to supporting V1, the extra code is not large, and there's no maintenance concern. I think we should support it for a few years, and then evaluate the situation once we're well past the transition. Another point: Our Linux/GNU friends support our old symbol versioning syntax in their linker, and there's value in making it easy for FOSS people to write one file that works in both places. ----- I just converted > 600 mapfiles in ON to the new syntax, and my feeling is that a tool to convert them would be of limited use. The actual syntax changes are simple and mechanical, particularly in the 99% that are related to symbol versioning. At the same time, I gained some big wins by rearranging things and applying conditional input directives, and a script can't help with that. The future blog article in the case materials (new_mapfiles.html) provides lots of conversion examples, and will be easy to find via google. As such, I'm not proposing such a tool as part of this case, but agree that it might be added downstream. - Ali
