On Tue, Jan 27, 2009 at 9:06 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote:> I'm strongly agains any target-specific and language-specific hacks in the > generic tree-conversion code. What if we decide to support objc on > non-darwin platforms someday? > This is theoretically possible (well, modulo all bunch of apple-local stuff > arond ;)). > > I believe, that TAI should place constant zeros in mergeable const section, > not in BSS. Could you please send me the .bc file? >I should have put this in darwin.h and called it from there. I think that there is a far more fundamental problem that affects more than Objective-C. Even with C code, we place a null string in a writable section, which isn't correct. I've attached the .bc file. The culprit is the @"\01LC" global. (This is generated with my hack, so it has an explicit "section".) Any suggestions for a back-end fix would be welcome, as I'm not a huge fan of hacking the front-end to get the sections for symbols correct. :-) -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: f.bc Type: application/octet-stream Size: 1072 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090127/c58b7d68/attachment.obj>
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. 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. -Eli
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
Hello, Bill> I should have put this in darwin.h and called it from there. I think > that there is a far more fundamental problem that affects more than > Objective-C. Even with C code, we place a null string in a writable > section, which isn't correct. I've attached the .bc file. The culprit > is the @"\01LC" global. (This is generated with my hack, so it has an > explicit "section".) Any suggestions for a back-end fix would be > welcomeFix commited :) Actually it was my fault. We have ConstantArray stuff for everything string-like but non-zero and ConstantAggregateZero for string-like but zero (rather odd!). I was not aware about such during writing of section selection code, thus missed the second opportunity. Now everything should be ok as of r63139. Let me know, if it still fails for you somehow. I'm currently in paper-deadline-really-soon-but-no-paper-yet mode and thus have really no free time, please consider adding testcase by yourself :) --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Tue, Jan 27, 2009 at 2:32 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Hello, Bill > >> I should have put this in darwin.h and called it from there. I think >> that there is a far more fundamental problem that affects more than >> Objective-C. Even with C code, we place a null string in a writable >> section, which isn't correct. I've attached the .bc file. The culprit >> is the @"\01LC" global. (This is generated with my hack, so it has an >> explicit "section".) Any suggestions for a back-end fix would be >> welcome > Fix commited :) Actually it was my fault. We have ConstantArray stuff > for everything string-like but non-zero and ConstantAggregateZero for > string-like but zero (rather odd!). I was not aware about such during > writing of section selection code, thus missed the second opportunity. > Now everything should be ok as of r63139. Let me know, if it still > fails for you somehow. > > I'm currently in paper-deadline-really-soon-but-no-paper-yet mode and > thus have really no free time, please consider adding testcase by > yourself :) >Anton, You rock!! Thanks for the fix. :-) Good luck on the paper! -bw