226597 - nsObjectFrame.cpp Warning: String literal converted to char* in initialization.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[timeless]

"/export/home/timeless/mozilla/layout/html/base/src/nsObjectFrame.cpp", line
2664: Warning: String literal converted to char* in initialization.

once for each line.

Comment 1

[timeless]

Attachment: use properly sized arrays

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why do we want to do it this way? Does the warning go away if we change the
structure member types to "const char*"?

Comment 3

[timeless]

yes it goes away, but drepper indicates that we get a penalty because the data
has to be copied in at runtime.

Comment 4

[Ulrich Drepper]

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.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Intriguing. Thanks Ulrich. I don't suppose you know how well your analysis
applies to Windows DLLs too?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 7

[Ulrich Drepper]

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.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Okay, I see. Thanks for that! Couldn't you extend prelinking to speculatively
resolve external references, though?

Comment 9

[Ulrich Drepper]

> 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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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!!

Comment 11

[timeless]

checked in