[LLVMdev] RFC: -fwritable-strings Change

[Bill Wendling]

On Tue, Jan 27, 2009 at 1:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Tue, Jan 27, 2009 at 1:00 PM, Bill Wendling <isanbard at gmail.com> wrote:
>> Even with C code, we place a null string in a writable
>> section, which isn't correct.
>
> You could say that, but it's not really wrong... say you had a 10
> kilobyte struct that was all null.  If you put it into a data section,
> it takes up 10k in the executable (unless Darwin has some unusual data
> section); it takes up no space at all in the BSS.  So naturally we'd
> prefer to put it in the BSS... for a 1 byte string that doesn't really
> matter, though.
>
Sure. I wasn't suggesting that all zero initialized variables be moved
out of the BSS section. :-) But if we place a null string in a
writable section and we don't have "writable strings" enabled, then,
well, it's in a writable section when it shouldn't be. It just happens
that (for Objective-C) our linker complains about this (it doesn't
complain about it for non-Objective-C languages). A non-Darwin
implementation of Objective-C would probably want to complain about
this (I'm guessing, as I don't know Obj-C well enough to know its
semantics).

> The thing that seems worrisome that you're depending on choices that
> could be made arbitrarily; no matter where the string is, it normally
> doesn't change the semantics of the program.  In certain situations,
> it could be a profitable transformation to, for example, put a string
> on the stack.  If the runtime environment is depending on it being in
> a specific place, you have to mark it so LLVM knows it can't do
> arbitrary manipulations on it.
>
I think that one of the problems with Objective-C (and why this became
a problem in the first place) is that it does require the string to be
in a specific place. The __builtin_CFString structure has, among other
things, a field that points to the actual string. When this string
isn't in the correct section, the linker complains.

-bw