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