On Tue, Jun 5, 2012 at 4:15 PM, Iain Sandoe <i...@codesourcery.com> wrote: > As it happens, the code should be as well-tested as for V1 as V2 ABI - > since it is conventional to test ObjC/NeXT at m32(V1) and m64(V2) [[and > also the GNU runtime (on Darwin)]]. > > So whilst Darwin is not as well-tested as linux, at least the coverage > is the same on all supported ObjC variants. > > You are right, it is broken for LTO. > > PR 48109 applies. > > I have two ideas at present for how to remove these two uses in ObjC FE: > > (1) Turn these 'ghost' items into real variables and use the existing > mechanism [meta-data attributes] to tag the items as needing special > handling by the back-end. This is done for other ObjC meta-data, since > they need to be placed in the correct sections for the runtime to find them. > > I posted a patch to implement this (allowing a target to intercept > assemble-variable at a high level) > > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02268.html > > there were changes requested by reviewers that I haven't been able to > find time to address just yet, but it might still be an appropriate > way forward. > > (2) Since this is Darwin/NeXT-specific, make the back-end recognise the > need to synthesise these two particular meta-data. This is not quite > so easy, but I haven't spent a lot of time on it yet.
Or: Since this is Darwin/NeXT-specific, hack around it by emitting these things as top-level asms. That would make things with with LTO also, and it is probably the easiest solution. It is a bit of a hack, but IMHO that's not a problem for something as target-specific as this. If I can turn that idea into a patch, can you test it for me? Ciao! Steven PS: nice to see you have a new employer ;-) Ciao! Steven
