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
On Tue, Jan 27, 2009 at 1:35 PM, Bill Wendling <isanbard at gmail.com> wrote:> On Tue, Jan 27, 2009 at 1:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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.If writable strings are disabled, writing to a string is undefined; it's not a bug if it doesn't crash.> 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.Mmm... if the __builtin_CFString structure has special properties to the linker, its strings really ought to be marked. There are all sorts of transformations which could make it impossible to distinguish otherwise; for example, a [4 x i8] constant could be turned into an i32 constant, or the empty string could be merged into an integer constant with the value 256. -Eli
On Tue, Jan 27, 2009 at 4:03 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Tue, Jan 27, 2009 at 1:35 PM, Bill Wendling <isanbard at gmail.com> wrote: >> 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. > > If writable strings are disabled, writing to a string is undefined; > it's not a bug if it doesn't crash. >That's not what I meant. Symbols and data should go in their correct sections no matter what the program eventual does.>> 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. > > Mmm... if the __builtin_CFString structure has special properties to > the linker, its strings really ought to be marked.Yup! That's what my hack was attempting to do.> There are all > sorts of transformations which could make it impossible to distinguish > otherwise; for example, a [4 x i8] constant could be turned into an > i32 constant, or the empty string could be merged into an integer > constant with the value 256. >Anton applied a much better patch in the back-end. -bw