search for: fwritable

Hello, Bill >> >> I don't see anything obvious wrong, but this is an easy area to >> break. >> I'd recommend running the gcc testsuite and checking for regressions. >> > Okay, that's a good plan. 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

Hi Bill, > My GCC-fu isn't great. Could someone review this to see if I broke anything? is there no better way?! Is this an objc problem, a darwin problem or...? If it is an objc problem, can't you just have objc set the section on the strings (DECL_SECTION_NAME) when it creates them? Anything but this patch, please! :) Ciao, Duncan.

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

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

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

On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > There is a problem with Objective-C code where a null string is placed > in the wrong section. If we have this code: > > #include <Foundation/Foundation.h> > void foo() { > NSLog(@""); > } > > The null string is defined like this: > > .const > .lcomm LC,1,0 ## LC > > Causing our

On Mon, Jan 26, 2009 at 4:45 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > >> There is a problem with Objective-C code where a null string is placed >> in the wrong section. If we have this code: >> >> #include <Foundation/Foundation.h> >> void foo() { >> NSLog(@"");

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

There is a problem with Objective-C code where a null string is placed in the wrong section. If we have this code: #include <Foundation/Foundation.h> void foo() { NSLog(@""); } The null string is defined like this: .const .lcomm LC,1,0 ## LC Causing our linker to go nuts, because it expects anonymous strings to be in the __cstring section. I came up with the attached

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