[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [Patch] Fix objc/48109
From:       Iain Sandoe <developer () sandoe-acoustics ! co ! uk>
Date:       2011-06-30 16:39:54
Message-ID: D26DEBED-3D2C-4644-B1EA-CBE928411F1B () sandoe-acoustics ! co ! uk
[Download RAW message or body]

Hi Richard(s),

thanks for the reviews.

before re-jigging - a couple of questions / points below.

On 30 Jun 2011, at 16:12, Richard Henderson wrote:

> On 06/30/2011 03:56 AM, Richard Guenther wrote:
>>>> It is only used by darwin at present - so nothing is split out  
>>>> for any other
>>>> target (the default hook is simply 'false').
>> Yes, I've seen that.  Still a hook like this should be generally  
>> useful,
>> and you still process through some pieces of assemble_variable
>> while you choose to skip some other piece - it should probably be
>> documented which part of assemble_variable is supposed to be handled
>> by the hook.

Yes, in order to avoid duplication of code, I placed the hook after  
all the set-up actions had been completed, but before any actual output.

Perhaps it would be better just to make the hook the first line of  
assemble_variable () and let the target take a (hopefully small) hit  
on replication of some of the actions of the varasm.c code.

Otherwise, noted about doc.

>> I'll defer to Richard for this (and the approval).

> I definitely want to see better documentation.  I don't know how to
> review the patch at the moment.  Some background for us non-darwin
> programmers would help as well; I don't know what's legal and what
> isn't when it comes to these sorts of odd non-definitions.

I guess, we new chaps assume you gurus know all... ;-) sorry...

An explanation here - as to what the hook is used for in this case.

I am not sure as to where the explanation needs to go (it doesn't seem  
appropriate for the hook, since that might be used for other purposes  
by other targets).

===

m32 Objective C (NeXT runtime) makes use of  anonymous meta-data,  
generated by the FE;
These data can be found by the runtime initialization - because they  
have a known organization and are placed in known sections.

However, because they are anonymous, there are no definitions or  
references to force the linker to include modules which only contain  
classes.

To cater for this, we have a class of symbols that are recognized by  
the darwin ld (ones beginning with ".objc_class_name_").  Satisfying  
linkage of these symbols is what ensures that appropriate modules are  
bound into the exe.

--

we arrange for the definitions to be emitted by asm like:

	.objc_class_name_MyClass = 0

.. and we arrange for the references to be generated by emitting:

	.lazy_reference .objc_class_name_MyClass

in neither case is any memory allocated for the entities represented.

In fact, one cannot allocate real memory and make a global  
objc_class_name_MyClass pointing to it - (which is essentially what  
GNU runtime does)  because, darwin's ld will recognize that it is not  
what's expected and fail (I tried that early on in seeking a solution)

The use of the hook is to allow us to generate 'real' variables for  
these items - and yet still intercept them and output the necessary asm.

That's the explanation - I think that it's present in darwin.c (in a  
shorter form) already.  I could expand on that and also replicate the  
discussion in objc-next-runtime-abi-01.c.

- would that be suitable?

> You're changing the set of variables emitted for non-darwin here
> too, as far as I can tell.  Is that actually desired?  I can't
> imagine what these variables are intended to achieve, given that
> they're byte sized and DECL_INITIAL = error_mark_node.

At present, non-NeXT targets (OK, that means non-mach-o as well,  
but..) the only real requirements are:

(a) that objc-next-runtime-abi-01.c should compile cleanly.
(b) that if someone invoked the function by some mistake elsewhere  
within ObjC, the result should be an error.

So, yes, if a non-darwin target were to call handle_next_impent () or  
handle_next_class_ref () the idea would be to cause a fail.
(perhaps there's a better way to do this - but it seemed reasonable at  
the time).

---

I'll address the other points as I re-jig.

thanks again,
Iain

[prev in list] [next in list] [prev in thread] [next in thread]