This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Fix ObjC @"string" machinery

Richard Henderson wrote:
> On Mon, Jun 27, 2005 at 06:46:49PM -0700, Ziemowit Laski wrote:
>>to refer to 'targetm.objc.next_runtime' (with c.opt mods as necessary).
> I don't like this.  Primarily because I'd *prefer* to have targetm
> be const.  At present several ports have backend-specific reasons
> why they need to modify it at runtime, but I don't want to add 
> reasons from the front ends.
> A better solution is to simply move flag_next_runtime to be a 
> generic flag, rather than a C front end flag.

I'm going to dare jump in here but please take my comments with a few
grains of salt as I haven't fully grokked the issue yet.

Darwin currently has two sections for storing ObjC strings:
in_objc_string_object and in_objc_constant_string_object
Dependent in the identifier name "NSConstantString" vs.
"NXConstantString" the string is currently created either in one or the
other section.

(Looking at this code (darwin.c machopic_select_section), I would assume
that the feature of selecting the constant string class via
-fconstant-string-class probably only works with one of these two class
 names on Darwin.)

I think, the patch is proposing to switch the semantics of choosing the
section from the identifier name to the -fgnu-runtime/-fnext-runtime switch.

The more I think about it, the less I think it is the correct solution,
independent of how one would access the flag from that file.

I assume that the difference in the sections is related to
const-ness/read-only status or something similar.  Therefor the two
classes NXConstantString/NSConstantString require different handling
(i.e. implementations).

Note that GNUstep uses -fconstant-string-class=NSConstantString so
presumably the proposed patch will probably put the string into the
wrong section on darwin for the GNU runtime.  (But it would probably go
unnoticed as I assume it will only lead to pessimization.)

Maybe the proper solution would be for the front end to adorn the type
(probably based on the identifier name) in a way for darwin.c to detect
which section to place it in.

But like I said, this is a lot of theorizing right now.

David Ayers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]