On Tue, Dec 13, 2005 at 10:30:59PM +0000, Saleem A. wrote: > On Tue, 13 Dec 2005, Mark Loeser wrote: > > > Basically what I'm looking for here is an easy to understand explanation of > > what textrels are, why they are bad, and why they should hold back marking a > > package stable. The only information I've been able to find states that > > they > > could cause a performance hit, but this doesn't seem to warrant banning them > > completely in my eyes. > > The big issue with > this is that the text segment is usually suppose to be read only for > security reasons. But because the text segment needs a relocation, it > needs to be read-write since the relocation happens at runtime > dynamically.
this is correct, a very good reason to fix TEXTRELs. another good reason is that since the segment cannot be mapped readonly, the memory cannot be shared across multiple processes ... each will need to have its own copy, thus wasting what could be significant memory resources. > The constant need to look up the address is what causes > the performance degredation. The performance degredation however is of > no worry to us. if by "constant" you mean "once everytime the code is loaded", then you are correct ... the relocations need to be rewritten everytime the image is loaded into memory by the dynamic loader (ldso), but after the first fixup, that's it, nothing else to be done. > > Getting a clear cut policy on exactly what issues should hold a package > > back > > from being marked stable is what I'm looking for. Issues like textrels, > > executable stacks, etc is what I'm looking for to be defined and explained > > why > > we are to always avoid them. This should be added to existing documentation > > policy so it is somewhere for new devs to know about, and existing devs to > > have for a reference. > > I agree, this would be very nice to have. It would make stabilization > of packages a little bit easier. working on it as i said ... i wish this e-mail could have been posted once i had more easier things to read :p -mike -- gentoo-dev@gentoo.org mailing list
