[llvm] r219976 - Initial version of Go bindings.

Eric Christopher echristo at gmail.com
Tue Oct 21 16:08:32 PDT 2014


On Tue Oct 21 2014 at 4:03:52 PM Peter Collingbourne <peter at pcc.me.uk>
wrote:

> On Tue, Oct 21, 2014 at 10:42:18PM +0000, Eric Christopher wrote:
> > >
> > >
> > > > Honestly I didn't think about it much. It should probably get
> migrated
> > > > along, because otherwise how would you pass that along?
> > >
> > > We might want the flag to appear in --cflags and --cxxflags. But it
> > > shouldn't
> > > appear in --cppflags, as that should contain only preprocessor flags.
> > >
> > >
> > Sure.
> >
> >
> > > > That said, stripping it out for now is fine. cgo should probably
> learn
> > > how
> > > > to deal with .dwo files at some point.
> > >
> > > Perhaps, but I'd expect that if cgo uses cppflags on its own it should
> be
> > > able to rely on those flags not changing the output format.
> > >
> > >
> > I'd be surprised if -g wasn't making it in there then since they're
> relying
> > on debug output?
> >
> > What's the actual command line look being passed to files that cgo wants?
>
> We found that it looked like this:
>
> gcc -w -Wno-error -o.../_cgo_.o -gdwarf-2 -c -xc -I.../include
> -I.../include -D_GNU_SOURCE -gsplit-dwarf -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I .../_obj_test/ -m64 -
>
> It appears that many of these flags (including -gdwarf-2) come from cgo
> itself, while the rest come from the user's c*flags.
>
> http://golang.org/src/cmd/cgo/gcc.go#L743
>
> That's probably the only way things could possibly work, as it's certainly
> possible for the user's c*flags to not include any -g flags.
>

Makes total sense.

OK with me then.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141021/bccc21a1/attachment.html>


More information about the llvm-commits mailing list