Objective C/C++ Compiler Drivers

Hey

Following up this thread on gcc-help:
http://gcc.gnu.org/ml/gcc-help/2010-08/msg00087.html

I added a objc and objcp compiler drivers, the objc one works so far as
much as i can tell i tested a hello world program with gccobjc hello.m
and the resulting a.out worked.

The compiler driver code i added for both is a vanilla driver, which
could fail though, since i don't tell anything to explicitly link their
respective runtime libraries though i would doubt the objc front-end i
just tested would generate working code without doing that so i may be
fine as is.

I am having problems with the objcp one so far it doesn't seem to get
installed so i need to look into this though i would like to get a
review on the patch as it stands so as i know i am on the right track.

--Phil
From 8b24db0dc92ba9fb1b91955fd0e358d89a2c462e Mon Sep 17 00:00:00 2001
From: redbrain <redbrain@gcc.gnu.org>
Date: Wed, 18 Aug 2010 04:35:41 +0100
Subject: [PATCH 1/2] add obj-c front-ends with compiler drivers

---
 gcc/objc/Make-lang.in  |   39 ++++++++++++++++++++++++++++-----------
 gcc/objc/objc-spec.c   |   38 ++++++++++++++++++++++++++++++++++++++
 gcc/objcp/Make-lang.in |   45 +++++++++++++++++++++++++++++++++------------
 gcc/objcp/objcp-spec.c |   38 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 137 insertions(+), 23 deletions(-)
 create mode 100644 gcc/objc/objc-spec.c
 create mode 100644 gcc/objcp/objcp-spec.c

Hi Philip,

On 18 Aug 2010, at 05:37, Philip Herron wrote:

> Following up this thread on gcc-help:
> http://gcc.gnu.org/ml/gcc-help/2010-08/msg00087.html

thanks for looking at this - ObjC* needs all the developers it can  
get :)

> The compiler driver code i added for both is a vanilla driver, which
> could fail though, since i don't tell anything to explicitly link  
> their
> respective runtime libraries

shouldn't be necessary to do anything explicit for a correctly  
installed compiler.

.. but ...
  you will still need to add the relevant  '-B's  & '-L's if you want  
to do uninstalled testing with the driver(s) named specifically -- the  
testsuite already handles the addition of -lxxx for objc/cpp when  
using the xgcc driver.

There is a 'gotcha' with headers that will break testing of darwin if  
you are not careful -- look at the objc-*.exp in gcc/testsuite/libs -  
they determine which runtime is in force and make sure to adjust the  
header paths accordingly.
[Darwin must find the system's installed ObjC headers when testing  
with -fnext-runtime, since the NeXT runtime is part of the system, not  
part of gcc.].

> though i would doubt the objc front-end i
> just tested would generate working code without doing that so i may be
> fine as is.

ObjC++ also needs to add lstdc++ (if you didn't so far, I've not read  
the patch yet).

> I am having problems with the objcp one so far it doesn't seem to get
> installed so i need to look into this though i would like to get a
> review on the patch as it stands so as i know i am on the right track.


I'll try and take a look later (although I'm not an approver of any  
sort, I should add).

cheers,
Iain

Hi Philip,

On 18 Aug 2010, at 05:37, Philip Herron wrote:
> I added a objc and objcp compiler drivers, the objc one works so far  
> as
> much as i can tell i tested a hello world program with gccobjc hello.m
> and the resulting a.out worked.

not quite sure how you achieved this, since -lobjc is not added  
AFAICT ...

does this work?

#include <objc/Object.h>

@interface Adder : Object
- (int) addone: (int)num;
@end

@implementation Adder
- (int) addone: (int)num
{ return num+1 ;
}
@end

#include <stdio.h>
int main ()
{
         int five;
   Adder *obj = [Adder new];
   five = [obj addone: 4 ];
   printf("no %d\n", five);
   return five;
}


> The compiler driver code i added for both is a vanilla driver,

right, and now you have to populate  lang_specific_driver ()

[ on the assumption that what is required cannot be achieved with  
specs, which is consistent with the other drivers]

If I was doing this I'd steal (& modify) the options parser from  
gfortran and use the lang_specific_driver from g++ as  a template for  
dealing with recognizing the case of PCH.

the steps, AFAIU are:

1/ parse the provided args to detect
   (a) whether this is a session involving linking
   (b) any libs the user has provided.
   (c) the need for a mathlib (on systems that use one)
   (d) permutations of libgcc
   (e) ** possibly, although not currently supported, the need for  
static linkage.

2/ if _not_ linking make sure that no linker commands get into the  
output - because this messes up PCH
     (actually, last time I checked, g++ does not work with PCH if you  
put -static-libstdc++ or any -Wl,...  on the cl).

3/ re-write the args with whatever additions and re-ordering of libs  
is needed,
    .. (in particular, for example, making sure that lm appears after  
lstdc++ )
     and wrapping of non-native-language filenames (e.g. compiling  
foo.c as if it were foo.m),

4/ tell the caller what you've done.

> I am having problems with the objcp one so far it doesn't seem to get
> installed

just an unwanted .PHONY, I suspect.

------

FWIW (at the risk of starting a debate.... ) :

I personally would prefer (in descending order of preference);

objc ... gcc-objc   (I don't think objc clashes with anything)

obj-c++ ... obj-g++ ... objc++ ... objg++ ...  gcc-obj-c++ ...


cheers,
Iain

On Wed, 18 Aug 2010, IainS wrote:

> If I was doing this I'd steal (& modify) the options parser from gfortran and
> use the lang_specific_driver from g++ as  a template for dealing with
> recognizing the case of PCH.

Please refactor into shared code instead of copying from one place to 
another with random changes.  For Obj-C++ you probably want to share all 
the existing g++ driver code.

I'm in the process of debugging a patch that moves lang_specific_driver to 
working with cl_decoded_option structures.  Lots of oddities in the 
existing lang_specific_driver code have shown up in the process and I've 
no real idea whether some of them have good reasons behind them.  For 
example, why do some drivers but not others have special treatment of 
0-character and 1-character operands (not always limited to "-" but 
sometimes including other 1-character operands) different from how they 
handle other non-option operands?  The comment

      /* We don't do this anymore, since we don't get them with minus
         signs on them.  */

that has also clearly been copied from one place to another doesn't make 
any sense to me.

On Aug 17, 2010, at 9:37 PM, Philip Herron wrote:
> I added a objc and objcp compiler drivers,

First, formalities...  Do you have your paper work for gcc done?  If not, if you want to contribute larger chunks, it is required.

> the objc one works so far as much as i can tell i tested a hello world program with gccobjc hello.m and the resulting a.out worked.

The likelihood of getting it wrong should be low.  I glanced at the patch, looks mostly fine to me.

> The compiler driver code i added for both is a vanilla driver, which
> could fail though, since i don't tell anything to explicitly link their
> respective runtime libraries though i would doubt the objc front-end i
> just tested would generate working code without doing that so i may be
> fine as is.

Mostly fine as is, but, we'd solicit the next step, which would be adding the -l flags as appropriate, and defaulting to objc for .c files...  As the C++ driver comes up, defaulting it to obj-c++ for the normal C++ extensions would be nice.  After that, well, can't recall anything that would need doing.  If anyone else can think of something, let them speak up!

> I am having problems with the objcp one so far it doesn't seem to get installed so i need to look into this though i would like to get a review on the patch as it stands so as i know i am on the right track.

If you exactly copy the g++ driver, you should be able to copy is semantics...  That'd be the first step.  I didn't diff between the two to look at the differences...  [ pause ] Ok, I looked at some of the differences...  In general, you want to get rid of the differences...  For example, I didn't see a use of program_transform_name.  Copy exactly, and only change the parts you are certain are wrong or don't apply and you'll have an easier time.

The other thing I'd change are the names, gccobjcp, mouthful.  Please use objc++ and objc as the driver names.  The long form of the drivers would be gobjc and gobjc++.  For ++less systems, following what they do for those system would be best.

On 18 August 2010 18:14, Mike Stump <mikestump@comcast.net> wrote:
> On Aug 17, 2010, at 9:37 PM, Philip Herron wrote:
>> I added a objc and objcp compiler drivers,
>
> First, formalities...  Do you have your paper work for gcc done?  If not, if you want to contribute larger chunks, it is required.
>
>> the objc one works so far as much as i can tell i tested a hello world program with gccobjc hello.m and the resulting a.out worked.
>
> The likelihood of getting it wrong should be low.  I glanced at the patch, looks mostly fine to me.
>
>> The compiler driver code i added for both is a vanilla driver, which
>> could fail though, since i don't tell anything to explicitly link their
>> respective runtime libraries though i would doubt the objc front-end i
>> just tested would generate working code without doing that so i may be
>> fine as is.
>
> Mostly fine as is, but, we'd solicit the next step, which would be adding the -l flags as appropriate, and defaulting to objc for .c files...  As the C++ driver comes up, defaulting it to obj-c++ for the normal C++ extensions would be nice.  After that, well, can't recall anything that would need doing.  If anyone else can think of something, let them speak up!
>
>> I am having problems with the objcp one so far it doesn't seem to get installed so i need to look into this though i would like to get a review on the patch as it stands so as i know i am on the right track.
>
> If you exactly copy the g++ driver, you should be able to copy is semantics...  That'd be the first step.  I didn't diff between the two to look at the differences...  [ pause ] Ok, I looked at some of the differences...  In general, you want to get rid of the differences...  For example, I didn't see a use of program_transform_name.  Copy exactly, and only change the parts you are certain are wrong or don't apply and you'll have an easier time.
>
> The other thing I'd change are the names, gccobjcp, mouthful.  Please use objc++ and objc as the driver names.  The long form of the drivers would be gobjc and gobjc++.  For ++less systems, following what they do for those system would be best.

Thanks for all the pointers you guys gave, when i started i wasnt
quite sure what would work or not! And yes i do have gnu copy
approval. I will endeavour to clean this up and do the changes in
driver names and let you guys know how i get on soon, i couldn't work
on this today had to help a friend move house but will work on this
tomorrow :)

That test you told me to try didnt work since i dont link in the objc
runtime library:

redbrain@omicron:~ $ gccobjc -fdump-tree-gimple test.m
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld:
/tmp/cc95Hin0.o: in function main:test.m(.text+0x1d): error: undefined
reference to 'objc_get_class'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld:
/tmp/cc95Hin0.o: in function main:test.m(.text+0x2f): error: undefined
reference to 'objc_msg_lookup'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld:
/tmp/cc95Hin0.o: in function main:test.m(.text+0x54): error: undefined
reference to 'objc_msg_lookup'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld:
/tmp/cc95Hin0.o: in function __objc_gnu_init:test.m(.text+0x9d):
error: undefined reference to '__objc_exec_class'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld:
/tmp/cc95Hin0.o: in function
__objc_class_ref_Object:test.m(.data+0x100): error: undefined
reference to '__objc_class_name_Object'
collect2: ld returned 1 exit status

But i can do that now the program which did work for me was:

#import <stdio.h>

int main( int argc, const char *argv[] ) {
    printf( "hello world\n" );
    return 0;
}

But i guess since all what's going on there is a c program with some
different c-preprocessor statements so no extra objc features were
actually being used.

--Phil

Hey all,

I started to work on this again for a little bit, i followed the
gcc/gfrotranspec.c compiler driver since its such a pristine driver
its hard not to copy it.

Though i would like a review since i am having problems with the
Make-lang.in to install the driver not quite sure what i've done
wrong, i am not great at writing make some pointers would be great, it
says i need to look at $(COMPILERS) or such for the install hooks.

--Phil

On Sat, 4 Sep 2010, Philip Herron wrote:

> Hey all,
> 
> I started to work on this again for a little bit, i followed the
> gcc/gfrotranspec.c compiler driver since its such a pristine driver
> its hard not to copy it.

My previous comments still apply: copying code with random changes is bad 
and leads to gratuitous divergence as subsequent improvements don't get 
applied to all the copies, refactoring so that code can be shared is good.  
It may be possible to reduce the C, C++ and Fortran drivers to a single 
piece of shared code that takes a datastructure describing the libraries 
required by the respective languages; certainly, patches that increase 
code sharing and reduce the amount of ObjC-specific code needed for an 
ObjC-specific driver would be a much better start than going straight into 
writing that driver.

On 4 September 2010 01:14, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sat, 4 Sep 2010, Philip Herron wrote:
>
>> Hey all,
>>
>> I started to work on this again for a little bit, i followed the
>> gcc/gfrotranspec.c compiler driver since its such a pristine driver
>> its hard not to copy it.
>
> My previous comments still apply: copying code with random changes is bad
> and leads to gratuitous divergence as subsequent improvements don't get
> applied to all the copies, refactoring so that code can be shared is good.
> It may be possible to reduce the C, C++ and Fortran drivers to a single
> piece of shared code that takes a datastructure describing the libraries
> required by the respective languages; certainly, patches that increase
> code sharing and reduce the amount of ObjC-specific code needed for an
> ObjC-specific driver would be a much better start than going straight into
> writing that driver.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Then does it make sense for a compiler driver to be generated from
some kind of a config, i agree i've always found the compiler drivers
a frustrating thing, since for the most part all will do pretty
similar things, most customizations would be add extra linker options
i guess. I am not sure if that means we would have a build system to
generate it from a bash script and add extra options to the
config-lang.in to generate this or something.

--Phil

On Sat, 4 Sep 2010, Philip Herron wrote:

> Then does it make sense for a compiler driver to be generated from
> some kind of a config, i agree i've always found the compiler drivers
> a frustrating thing, since for the most part all will do pretty
> similar things, most customizations would be add extra linker options
> i guess. I am not sure if that means we would have a build system to
> generate it from a bash script and add extra options to the
> config-lang.in to generate this or something.

I am suggesting something much simpler: incremental refactoring of the 
existing code, moving shared utility functions to gcc.c, so that in the 
end most drivers can call a shared function and pass a C structure to it.  
Not anything requiring generator programs.

For example, you might adapt the Fortran functions such as append_arg to 
allocate space dynamically rather than hardcoding limits on the size of 
the new array of options based on the old one, move them to gcc.c with 
declarations in gcc.h and make all drivers use them.  That could be one of 
the incremental patches.  Subsequent ones might try to identify what is 
common about the logic to add language-specific libraries.

There is an idea that we don't really want all these drivers at all - we 
want "gcc" to link in the right libraries automatically for whatever 
languages were used for the object files it is asked to link - which 
certainly requires those libraries to be described by suitable 
datastructures gcc.c can use.

On 4 September 2010 01:29, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sat, 4 Sep 2010, Philip Herron wrote:
>
>> Then does it make sense for a compiler driver to be generated from
>> some kind of a config, i agree i've always found the compiler drivers
>> a frustrating thing, since for the most part all will do pretty
>> similar things, most customizations would be add extra linker options
>> i guess. I am not sure if that means we would have a build system to
>> generate it from a bash script and add extra options to the
>> config-lang.in to generate this or something.
>
> I am suggesting something much simpler: incremental refactoring of the
> existing code, moving shared utility functions to gcc.c, so that in the
> end most drivers can call a shared function and pass a C structure to it.
> Not anything requiring generator programs.
>
> For example, you might adapt the Fortran functions such as append_arg to
> allocate space dynamically rather than hardcoding limits on the size of
> the new array of options based on the old one, move them to gcc.c with
> declarations in gcc.h and make all drivers use them.  That could be one of
> the incremental patches.  Subsequent ones might try to identify what is
> common about the logic to add language-specific libraries.
>
> There is an idea that we don't really want all these drivers at all - we
> want "gcc" to link in the right libraries automatically for whatever
> languages were used for the object files it is asked to link - which
> certainly requires those libraries to be described by suitable
> datastructures gcc.c can use.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Ah ok i see what you mean now, thanks by the way. I'll play around
with that now and see what happens and do it for the objc front-end
first.

--Phil