"/export/home/timeless/mozilla/layout/html/base/src/nsObjectFrame.cpp", line 2664: Warning: String literal converted to char* in initialization. once for each line.
Why do we want to do it this way? Does the warning go away if we change the structure member types to "const char*"?
yes it goes away, but drepper indicates that we get a penalty because the data has to be copied in at runtime.
With the proposed patch the total amount of data, size of read-writable data, and code goes down. So far each array entry needs two pointers and two (relative) relocations. And the array itself is in read-writable memory. Accessing a string requires a memory load. With the new code the array is in read-only memory, no relocations are needed, and accesses compute the strings address relative to the array address (no additional memory access). The memory overhead caused by using the maximum string length for each field is more than compensated by the pointer (4 or 8 byte) plus the relocation (8 - 24 bytes, depending on the platform). And the program starts up faster since no runtime relocations are needed. Using this new format is 100% the right way. For more info, see http://people.redhat.com/drepper/dsohowto.pdf.
Intriguing. Thanks Ulrich. I don't suppose you know how well your analysis applies to Windows DLLs too?
A few comments: Section 1.5.4: Topological sort can usually be done in linear time. I assume prelinking would avoid executing the two relocations? Would it also avoid having to load the two relocations into memory? Two other questions for my curiosity, if you don't mind: Have you considered using tries to store symbol tables, instead of hashtables? Suppose prelinking is really effective. Would it make sense to abandon PIC code and hope that prelinking avoids most copy-on-writes?
First, I know not much about windows. The proposed code cannot hurt, though. Maybe the benefits are not that big. Re prelinking: yes, prelinking can avoid the relative relocations. But only if the DSOs can really be prelinked. There are a few conditions (I think moz's DSOs are fine). But importantly, the relocations are still present in the binary. I.e., the address space consumption is still there. And probably even memory consumption, since the conflict relocations always have to be processed and this causes the pages with the relocations to be paged in. And in fact on ia32, due to the nature of the used Elf32_Rel relocation, it might be that all relocations get duplicated and there are additional Elf32_Rela relocations. > Suppose prelinking is really effective. Would it make sense to abandon PIC > code and hope that prelinking avoids most copy-on-writes? You want to write DSOs without PIC? Prelinking won't help there much. You'll end up with all kinds of text relocations. Every access to an external symbol (like virtual function tables, variables) will cause a text relocation which is not resolved at prelink time.
Okay, I see. Thanks for that! Couldn't you extend prelinking to speculatively resolve external references, though?
> Couldn't you extend prelinking to speculatively resolve external references, > though? This is done, of course, but the lookup scope depends on the context. The DSO paper cited above explains the lookup scope. A DSO used in different context will have different scopes and the results of the lookups might be different. The will cause text relocations, possibly many of them.
> the results of the lookups might be different. They might, but if they're normally not different, then few text relocations would need to be applied and non-PIC code might make sense. Right? Especially on 64-bit architectures where there's lots more virtual address space and it's much easier to avoid collisions. I guess I should look at ld.so statistics and see for myself. Thanks!!
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.