Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Ralf Wildenhues ralf.wildenh...@gmx.de writes:

 I casually looked at libgo/{Makefile.am,configure.ac}.

Thanks for the review.


 You don't need to list .c files in the BUILT_SOURCES variable if they
 are also listed in some prog_SOURCES variable (and are not
 undocumented prerequisites for other targets).  make will know that it
 needs to create these files.  (Omitting BUILT_SOURCES saves a recursive
 make invocation in practice.)

Fixed.


 if LIBGO_IS_386
 GOARCH = 386
 else
 if LIBGO_IS_X86_64
 GOARCH = amd64
 else
 if LIBGO_IS_ARM
 GOARCH = arm
 else
 GOARCH = unknown
 endif
 endif
 endif

 I wouldn't write Automake conditionals deeply nested, it makes for long
 lines and quadratic number of characters in Makefile.in when the number
 of conditionals increases.  But who am I telling that.  ;-)
 You could just AC_SUBST([GOARCH]) and GOOS from configure.ac; but this
 is a really minor stylistic issue.

It's ugly but it puts the value where it is used, rather than splitting
it between configure.ac and Makefile.am.  This makes it easier to
understand what is happening.

If only the person who implemented automake conditionals had added elif.
What a maroon.


 Several %/check targets use 'mkdir -p'.  While that is quite portable
 nowadays, there are still mkdir implementations that are racy when run
 in parallel.  You can use $(MKDIR_P) instead.

Fixed.


 I suppose portability to systems where OBJEXT is .obj is not a question
 at this point.

Not really, but I changed .o to .$(OBJEXT) anyhow.

All patches committed to gccgo branch.  Thanks again for the review.

Ian

Re: Discussion about merging Go frontend

[Ralf Wildenhues]

Hello,

* Joseph S. Myers wrote on Sat, Nov 06, 2010 at 11:41:17PM CET:
 On Wed, 3 Nov 2010, Ian Lance Taylor wrote:
 
  There is also the libgo directory.  The contents of libgo/go are a copy
  of the standard Go library and I don't think a review of that would be
  useful.  But it would be reasonable to review the contents of libgo
  outside of libgo/go.  This code can found on the gccgo branch in the
  libgo subdirectory.
 
 I don't propose to review this.  A build-system maintainer might be most 
 useful there.

I casually looked at libgo/{Makefile.am,configure.ac}.

You don't need to list .c files in the BUILT_SOURCES variable if they
are also listed in some prog_SOURCES variable (and are not
undocumented prerequisites for other targets).  make will know that it
needs to create these files.  (Omitting BUILT_SOURCES saves a recursive
make invocation in practice.)

 if LIBGO_IS_386
 GOARCH = 386
 else
 if LIBGO_IS_X86_64
 GOARCH = amd64
 else
 if LIBGO_IS_ARM
 GOARCH = arm
 else
 GOARCH = unknown
 endif
 endif
 endif

I wouldn't write Automake conditionals deeply nested, it makes for long
lines and quadratic number of characters in Makefile.in when the number
of conditionals increases.  But who am I telling that.  ;-)
You could just AC_SUBST([GOARCH]) and GOOS from configure.ac; but this
is a really minor stylistic issue.

Several %/check targets use 'mkdir -p'.  While that is quite portable
nowadays, there are still mkdir implementations that are racy when run
in parallel.  You can use $(MKDIR_P) instead.

I suppose portability to systems where OBJEXT is .obj is not a question
at this point.

configure.ac didn't really show up much at a glance.

Cheers,
Ralf

Re: Discussion about merging Go frontend

[Eric Botcazou]

 2010-10-28  Ian Lance Taylor  i...@google.com

   * lto-objfile.c: New file.
   * lto-elf.c: Remove file.

This has removed the support for compatible architectures present in lto-elf.c 
and hasn't added any replacement in libiberty, so a bunch of LTO tests fail 
again on 32-bit SPARC/Solaris.

The old code reads:

/* Return true if ELF_MACHINE is compatible with the cached value of the
   architecture and possibly update the latter.  Return false otherwise.

   Note: if you want to add more EM_* cases, you'll need to provide the
   corresponding definitions at the beginning of the file.  */

static bool
is_compatible_architecture (Elf64_Half elf_machine)
{
  if (cached_file_attrs.elf_machine == elf_machine)
return true;

  switch (cached_file_attrs.elf_machine)
{
case EM_SPARC:
  if (elf_machine == EM_SPARC32PLUS)
{
  cached_file_attrs.elf_machine = elf_machine;
  return true;
}
  break;

case EM_SPARC32PLUS:
  if (elf_machine == EM_SPARC)
return true;
  break;

default:
  break;
}

  return false;
}

so it was not only accepting object files with compatible architectures in the 
same LTO compilation, but also updating the current architecture for later 
write operations.  This is modelled on the linker.

-- 
Eric Botcazou

Re: Discussion about merging Go frontend

[Joseph S. Myers]

On Wed, 3 Nov 2010, Ian Lance Taylor wrote:

 Joseph S. Myers jos...@codesourcery.com writes:
 
  I think new front ends should be reviewed for general style, coding 
  conventions, use of deprecated interfaces, unportabilities etc., just as 
  new back ends should be reviewed.
 
 Would anybody care to volunteer to review the Go frontend on these
 grounds?  The code can be found on the gccgo branch in the gcc/go
 subdirectory.

I have now posted reviews of this code for various issues, though I think 
it could do with more eyes on it, from front-end maintainers, build-system 
maintainers and others.  I did not go exhaustively through all the code in 
gofrontend/.

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00640.html
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00654.html
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00656.html

 There is also the libgo directory.  The contents of libgo/go are a copy
 of the standard Go library and I don't think a review of that would be
 useful.  But it would be reasonable to review the contents of libgo
 outside of libgo/go.  This code can found on the gccgo branch in the
 libgo subdirectory.

I don't propose to review this.  A build-system maintainer might be most 
useful there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Joseph S. Myers jos...@codesourcery.com writes:

 I think new front ends should be reviewed for general style, coding 
 conventions, use of deprecated interfaces, unportabilities etc., just as 
 new back ends should be reviewed.

Would anybody care to volunteer to review the Go frontend on these
grounds?  The code can be found on the gccgo branch in the gcc/go
subdirectory.

There is also the libgo directory.  The contents of libgo/go are a copy
of the standard Go library and I don't think a review of that would be
useful.  But it would be reasonable to review the contents of libgo
outside of libgo/go.  This code can found on the gccgo branch in the
libgo subdirectory.

And there is the testsuite, which I suppose I will post separately.

Ian

Re: Discussion about merging Go frontend

[Paolo Bonzini]

On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:

Tom Tromeytro...@redhat.com  writes:


Ian == Ian Lance Taylori...@google.com  writes:


Ian  This patch puts the code in libiberty, but it could equally well go in
Ian  gcc.  Anybody want to make an argument one way or another?

Ian  +extern const char *
Ian  +objfile_attributes_compare (objfile_attributes *attrs1,

GDB already uses the name objfile for one of its modules.
I don't think we have any name clashes with this patch right now, but I
would prefer to avoid the eventual confusion.
So, if this is in libiberty, could it please have a different name?


Sure.

Any suggestions?


readobj/objread?

Paolo

Re: Discussion about merging Go frontend

[Paolo Bonzini]

On 11/02/2010 11:50 AM, Paolo Bonzini wrote:

On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:

Tom Tromeytro...@redhat.com writes:


Ian This patch puts the code in libiberty, but it could equally well
go in
Ian gcc. Anybody want to make an argument one way or another?

Ian +extern const char *
Ian +objfile_attributes_compare (objfile_attributes *attrs1,

GDB already uses the name objfile for one of its modules.
I don't think we have any name clashes with this patch right now, but I
would prefer to avoid the eventual confusion.
So, if this is in libiberty, could it please have a different name?


Sure.

Any suggestions?


readobj/objread?


This obviously meant objread/objwrite. :)

Paolo

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Joseph S. Myers jos...@codesourcery.com writes:

 On Sat, 23 Oct 2010, Ian Lance Taylor wrote:

 affect other languages.  The only thing I hope to clean up further
 before the merge is additional separation between the Go frontend proper
 and the gcc-specific interface.  I'm not going to have time to do the
 full planned separation, which I will continue to work on, but I hope to
 have the proper framework in place for future work.

 Will the front end use its own text domain for i18n of messages, or the 
 gcc domain?  Whatever the answer, do you need changes to po/exgettext or 
 similar to cause all the messages to be properly extracted?

Good questions but I simply don't know.  If anybody has any advice I
would be happy to hear it.

The current Go frontend source code marks text strings which require
localization just as gcc code does: with _(), except when directly
calling error or similar functions.  I suppose my inclination is to
simply continue doing that, and leaving the details of localization out
of the frontend.  In which case the front end will not use its own text
domain for internationalization.  It seems to me that this is a decision
which can be changed later with only mild stress.

Looking at po/exgettext, a script whose existence I had not previously
suspected, it appears that it will need some minor changes to look at
C++ files.  I will tackle that at some point after the merge.


 There are three new source code directories: gcc/go, libgo, and elfcpp.
 The last is currently part of the src repository, where it is used by
 gold.  I propose moving the master copy of elfcpp to gcc, and handling
 it like libiberty.

 How is elfcpp used?  Is this front end in some way restricted to ELF 
 targets, or more functional with them?  (In general, to what extent are 
 the front end and library portable to different targets - how much work, 
 if any, is needed to get them building and working for a new target 
 (architecture or OS)?  Would the sort of target changes needed be risky 
 for Stage 3?  What about host portability?)

The simple_object work I committed this morning means that elfcpp is no
longer required.

The front end should be portable to new hosts and targets; I don't know
of any issues there (well, I know of one minor issue with a Mach-O
target which I intend to fix).  The library is not too hard to port--it
has been ported to RTEMS already, though I'm sure a Windows port would
have some difficulties.  The library does currently use the pthreads
interface directly; I don't know how hard it would be to change to use
gcc's gthread interface.


 The following other files are changed:

 You don't mention documentation.  Does the front end have its own manual?  
 Whether or not it does, the new-front-end checklist (Front End in 
 sourcebuild.texi) lists places in the documentation that need updating for 
 a new front end (install.texi, contrib.texi, frontends.texi, 
 standards.texi, invoke.texi, sourcebuild.texi - plus web page etc. updates 
 for merging to trunk).

Good point.  I have not dealt with doc changes yet.


 gcc/opts.c
 gcc/toplev.c
 gcc/debug.h
 gcc/flag-types.h
 gcc/c-family/c-lex.c
 gcc/Makefile.in
   Add support for -ggo, used when building runtime library.

 Note that all -g* options are also handled in a case statement in 
 java/jvspec.c, though that might well better be handled through specs, and 
 I don't know if -ggo makes sense at all for Java.

Thanks.  I doubt -ggo would ever make sense for Java but that seems easy
enough to handle.

 I think appropriate coding standards documentation for this front end is 
 needed.  Possibly in the form of a description of how the coding standards 
 differ from the general conventions for C++ in existing parts of GCC at 
 http://gcc.gnu.org/wiki/CppConventions, though those would need merging 
 into codingconventions.html before being used as a basis for conventions 
 actually used on GCC trunk.

I think the conventions I used are the same as the ones in
CppConventions, but, yes, point taken.

 The front end's langhooks don't seem to have been updated for the 
 separation of the init_options and init_options_struct hooks.

Thanks, will fix.

 I presume you will be posting the front end and other changes for review 
 (or, I suppose, given the size of the changes, explicitly stating that you 
 propose for review the diffs between particular revisions of trunk and a 
 branch given by a particular svn diff command) as indicated in 
 http://gcc.gnu.org/ml/gcc/2010-01/msg00504.html.

I will post all changes outside of the gcc/go and libgo directories for
review, certainly.  I would also appreciate review for the code in
gcc/go and libgo on the branch.  Whether review is required for that
code is an interesting question.  I have been assuming that I would
become the initial maintainer for the gcc/go and libgo directories.  As
such, I would be permitted to make changes to those directories without
review.  So is review required for the 

Re: Discussion about merging Go frontend

[Tom Tromey]

 Ian == Ian Lance Taylor i...@google.com writes:

Ian This patch puts the code in libiberty, but it could equally well go in
Ian gcc.  Anybody want to make an argument one way or another?

Ian +extern const char *
Ian +objfile_attributes_compare (objfile_attributes *attrs1,

GDB already uses the name objfile for one of its modules.
I don't think we have any name clashes with this patch right now, but I
would prefer to avoid the eventual confusion.
So, if this is in libiberty, could it please have a different name?

thanks,
Tom

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Tom Tromey tro...@redhat.com writes:

 Ian == Ian Lance Taylor i...@google.com writes:

 Ian This patch puts the code in libiberty, but it could equally well go in
 Ian gcc.  Anybody want to make an argument one way or another?

 Ian +extern const char *
 Ian +objfile_attributes_compare (objfile_attributes *attrs1,

 GDB already uses the name objfile for one of its modules.
 I don't think we have any name clashes with this patch right now, but I
 would prefer to avoid the eventual confusion.
 So, if this is in libiberty, could it please have a different name?

Sure.

Any suggestions?

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

H.J. Lu hjl.to...@gmail.com writes:

 Will put

 if [ Go is enabled ]; then
   boot_language=yes
 fi

 in cp/config-lang.in work?

Probably, but why should I change cp/config-lang.in if I want to support
Go?  Everything required to support Go should, as much as possible, be
in the Go frontend.

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Dave Korn dave.korn.cyg...@gmail.com writes:

 On 30/10/2010 19:24, Richard Henderson wrote:
 On 10/30/2010 11:37 AM, Dave Korn wrote:
 Uh, really?  I thought there were like a half-dozen lto sections...
   Which we iterate over just once, and record them all in a hash table from
 the per-section callback, unless I've missed something.
 
 Oh, right.  Nevermind then.
 
 
 r~

   It'd be worth putting a warning comment on the find_section (no s)
 function saying that it's pretty inefficient and that it is best practice to
 call find_sections just once and record details rather than make multiple
 calls to find_section.  (Both lto FE and lto-plugin are already architected
 that way.)

 cheers,
   DaveK

I added a sentence Note that calling this multiple times is
inefficient; use objfile_find_sections instead.

I added the function because it's what the gccgo frontend needs: it only
needs to find one section.

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Dave Korn dave.korn.cyg...@gmail.com writes:

   Attached are the revised version of the file, and a diff to show what I
 changed.  With this version, all the tests in gcc.dg/lto/lto.exp pass as
 before (i.e. there are still a couple of pre-existing FAILs that aren't 
 affected).

Excellent, thanks.  I have incorporated your objfile-coff.c in my
working directory, and will commit it when I commit the whole patch set.

I think it can be committed as soon as objfile-mach-o.c is working.

Ian

Re: Discussion about merging Go frontend

[Florian Weimer]

* Ian Lance Taylor:

 The Go frontend was approved for inclusion with gcc by the steering
 committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html .

How general is the garbage collector and its support infrastructure in
the compiler?  AFAICS, it's precise, unlike the Boehm/Dehmers/Weiser
collector used by the Java front end.

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Florian Weimer f...@deneb.enyo.de writes:

 * Ian Lance Taylor:

 The Go frontend was approved for inclusion with gcc by the steering
 committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html .

 How general is the garbage collector and its support infrastructure in
 the compiler?  AFAICS, it's precise, unlike the Boehm/Dehmers/Weiser
 collector used by the Java front end.

The garbage collector is a work in progress.  What I say here is how it
works at present, but everything will change in some as yet undetermined
manner.

At the moment the only compiler support for the garbage collector is
that some allocations are marked as not containing pointers.  Those
blocks are ignored when scanning.  When scanning memory blocks which may
contain pointers, which includes the stack, the scanning is
conservative: an integer value which happens to look like a pointer will
cause the block to which it points to be marked as live.

Ian

Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 01:23, Richard Henderson wrote:

 +  if (!objfile_internal_read (objfile-descriptor,
 +  objfile-offset + eor-shoff + shdr_size,
 +  shdrs,
 +  shdr_size * (shnum - 1),
 +  errmsg, err))
 
 Do we really want to keep re-reading section data for every section
 lookup we do?  Can't we do this in objfile_open_read?

  It should only be necessary to do one section lookup per object file anyway.
 Keep extra data hanging around in memory in the backend just so that we can
write algorithmically inefficient code in the client?  Seems like a bad
tradeoff to me!

 +  set_32 (hdr + offsetof (struct external_scnhdr, s_flags),
 +  (STYP_DATA | IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE
 +   | IMAGE_SCN_MEM_SHARED | IMAGE_SCN_MEM_READ));
 
 You're not recording alignment in the coff object file?

  It looks to me like he's recording an alignment of 1 byte.

 IMAGE_SCN_ALIGN_NBYTES, 1 = N = 8192, are all defined
 with a simple function in that nibble.

  The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever need
for LTO sections.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Paolo Bonzini]

On 10/30/2010 05:30 AM, H.J. Lu wrote:

Will put

if [ Go is enabled ]; then
   boot_language=yes
fi

in cp/config-lang.in work?


It's a bit backwards, no?

Paolo

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 02:31, Ian Lance Taylor wrote:

 This implements an object file reader/writer which does everything
 required by LTO and gccgo.  The ELF code works.  I have not tested the
 Mach-O and COFF code at all beyond compiling it; I hope that somebody
 else can test those targets and fix them.
 
 With this patch, libelf is no longer needed.

  Almost, but not quite!  The attached patch switches the lto-plugin over to
use the new objfile reader as well.

lto-plugin/ChangeLog:

* configure.ac: Don't use libelf, don't source config.gcc.
(LIBELFLIBS): Delete.
(LIBELFINC): Delete.
(LTO_FORMAT): Delete.
(SYM_STYLE): New AC_SUBST var set based on $target.
* Makefile.am (LIBELFLIBS): Delete.
(LIBELFINC): Delete.
(LTO_FORMAT): Delete.
(SYM_STYLE): Import.
(AM_CPPFLAGS): Use it.  Don't use LIBELFINC.
(liblto_plugin_la_SOURCES): Don't use LTO_FORMAT, don't include
any object-format-specific source file in the link.
(liblto_plugin_la_LIBADD): Don't use LIBELFLIBS.
* configure: Regenerate.
* Makefile.in: Regenerate.
* lto-plugin-elf.c: Delete.
* lto-plugin-coff.c: Delete.
* lto-plugin.h: Delete.
* lto-plugin.c (O_BINARY): Definition moved here from lto-plugin.h.
(LTO_SEGMENT_NAME): New definition.
(LTO_SECTION_PREFIX): Definition moved here from lto-plugin.h.
(LTO_SECTION_PREFIX_LEN): New definition.
(struct sym_aux): Struct definition moved here from lto-plugin.h.
(struct plugin_symtab): Likewise.
(struct plugin_objfile): Likewise.
(struct plugin_objfile): New struct def.
(enum symbol_style): New enum type.
(add_symbols): Make static.
(claimed_files): Likewise.
(num_claimed_files): Likewise.
(sym_style): New global.
(check): Make static.
(parse_table_entry): Likewise.  Respect sym_style when extracting
symbol from symtab entry.
(translate): Make static.
(resolve_conflicts): Likewise.
(process_symtab): New function, per-section callback version of
old object-format-specific handling from deleted lto-plugin-elf.c.
(claim_file_handler): Convert ELF-specific version from deleted
lto-plugin-elf.c to objfile interface and move here.
(process_options): Allow new '-sym-style=' option.
(onload): Don't call deleted onload_format_checks hook.

  Bootstrapped and tested all languages except java and ada on
x86_64-unknown-linux-gnu, no regressions.  There are still a couple of bugs to
iron out of the COFF-specific part of the objfile reader which I'll have fixed
later today.

  OK for trunk (once the objfile changes have gone in)?

cheers,
  DaveK

Index: lto-plugin/lto-plugin-elf.c
===
--- lto-plugin/lto-plugin-elf.c	(revision 166059)
+++ lto-plugin/lto-plugin-elf.c	(working copy)
@@ -1,157 +0,0 @@
-/* LTO plugin for gold.
-   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
-   Contributed by Rafael Avila de Espindola (espind...@google.com).
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; see the file COPYING3.  If not see
-http://www.gnu.org/licenses/.  */
-
-#include assert.h
-#include string.h
-#include stdio.h
-#include libiberty.h
-#include stdlib.h
-#include inttypes.h
-
-/* The presence of gelf.h is checked by the toplevel configure script.  */
-#include gelf.h
-
-/* Common definitions that the object format dependent code needs.  */
-#include lto-plugin.h
-
-/* Process all lto symtabs of file ELF. */
-
-static int
-process_symtab (Elf *elf, struct plugin_symtab *out)
-{
-  int found = 0;
-  Elf_Scn *section = 0;
-  GElf_Ehdr header;
-  GElf_Ehdr *t = gelf_getehdr (elf, header);
-  if (t == NULL)
-return 0;
-  assert (t == header);
-
-  while ((section = elf_nextscn(elf, section)) != 0)
-{
-  GElf_Shdr shdr;
-  GElf_Shdr *tshdr = gelf_getshdr (section, shdr);
-  Elf_Data *symtab;
-  const char *t;
-  assert (tshdr == shdr);
-  t = elf_strptr (elf, header.e_shstrndx, shdr.sh_name);
-  assert (t != NULL);
-  if (strncmp (t, LTO_SECTION_PREFIX, strlen (LTO_SECTION_PREFIX)) == 0)
-	{
-	  char *s = strrchr (t, '.');
-	  if (s)
-	  sscanf (s, .%x, out-id);
-	  symtab = elf_getdata (section, NULL);
-	  translate (symtab-d_buf, symtab-d_buf + symtab-d_size, out);
-	 

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 02:31, Ian Lance Taylor wrote:

   * objfile-coff.c: New file.

  A few bugs have cropped up:

 +  if (namebuf[0] == '/')
 + {
 +   size_t strindex;
 +   char *end;
 +
 +   strindex = strtol (namebuf, end, 10);

  Needs to be strtol (namebuf + 1, 

 +  /* We don't write out any symbols.  We'll see if that causes any
 + problems.  */

  Not a chance of getting away with that, I'm afraid.  Everything expects
there to be file and section symbols and their auxiliaries.

 +  set_16 (hdr + offsetof (struct external_filehdr, f_magic), attrs-magic);
 +  set_16 (hdr + offsetof (struct external_filehdr, f_magic), nscns);

  Cut'n'pasto.  Second f_magic should be f_nscns.

 +   name_offset += namelen;

  Also needs to be namelen + 1.

  Attached are the revised version of the file, and a diff to show what I
changed.  With this version, all the tests in gcc.dg/lto/lto.exp pass as
before (i.e. there are still a couple of pre-existing FAILs that aren't 
affected).

cheers,
  DaveK
/* objfile-coff.c -- routines to manipulate COFF object files.
   Copyright 2010 Free Software Foundation, Inc.
   Written by Ian Lance Taylor, Google.

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option) any
later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, 51 Franklin Street - Fifth Floor,
Boston, MA 02110-1301, USA.  */

#include config.h
#include libiberty.h
#include objfile.h

#include errno.h
#include stddef.h

#ifdef HAVE_STDLIB_H
#include stdlib.h
#endif

#ifdef HAVE_STDINT_H
#include stdint.h
#endif

#ifdef HAVE_STRING_H
#include string.h
#endif

#ifdef HAVE_INTTYPES_H
#include inttypes.h
#endif

#include objfile-common.h

/* COFF structures and constants.  */

/* COFF file header.  */

struct external_filehdr
{
  unsigned char f_magic[2]; /* magic number */
  unsigned char f_nscns[2]; /* number of sections   */
  unsigned char f_timdat[4];/* time  date stamp*/
  unsigned char f_symptr[4];/* file pointer to symtab   */
  unsigned char f_nsyms[4]; /* number of symtab entries */
  unsigned char f_opthdr[2];/* sizeof(optional hdr) */
  unsigned char f_flags[2]; /* flags*/
};

/* Bits for filehdr f_flags field.  */

#define F_EXEC  (0x0002)
#define IMAGE_FILE_SYSTEM   (0x1000)
#define IMAGE_FILE_DLL  (0x2000)

/* COFF section header.  */

struct external_scnhdr
{
  unsigned char s_name[8];  /* section name */
  unsigned char s_paddr[4]; /* physical address, aliased s_nlib */
  unsigned char s_vaddr[4]; /* virtual address  */
  unsigned char s_size[4];  /* section size */
  unsigned char s_scnptr[4];/* file ptr to raw data for section */
  unsigned char s_relptr[4];/* file ptr to relocation   */
  unsigned char s_lnnoptr[4];   /* file ptr to line numbers */
  unsigned char s_nreloc[2];/* number of relocation entries */
  unsigned char s_nlnno[2]; /* number of line number entries*/
  unsigned char s_flags[4]; /* flags*/
};

/* The length of the s_name field in struct external_scnhdr.  */

#define SCNNMLEN (8)

/* Bits for scnhdr s_flags field.  This includes some bits defined
   only for PE.  This may need to be moved into coff_magic.  */

#define STYP_DATA   (1  6)
#define IMAGE_SCN_ALIGN_1BYTES  (1  20)
#define IMAGE_SCN_MEM_DISCARDABLE   (1  25)
#define IMAGE_SCN_MEM_SHARED(1  28)
#define IMAGE_SCN_MEM_READ  (1  30)

/* COFF symbol table entry.  */

#define E_SYMNMLEN  8   /* # characters in a symbol name*/

struct external_syment
{
  union
  {
unsigned char e_name[E_SYMNMLEN];

struct
{
  unsigned char e_zeroes[4];
  unsigned char e_offset[4];
} e;
  } e;

  unsigned char e_value[4];
  unsigned char e_scnum[2];
  unsigned char e_type[2];
  unsigned char e_sclass[1];
  unsigned char e_numaux[1];
};

/* Length allowed for filename in aux sym format 4.  */

#define E_FILNMLEN  18

/* Omits x_sym and other unused variants.  */

union external_auxent
{
  /* Aux sym format 4: file.  */
  union
  {
char x_fname[E_FILNMLEN];
struct
{
  unsigned char x_zeroes[4];
  unsigned char x_offset[4];
} x_n;
  } x_file;
  /* Aux sym format 5: section.  */
  struct
  {
unsigned 

[PATCH] Enable linker plugin for windows [was Re: Discussion about merging Go frontend]

[Dave Korn]

On 30/10/2010 11:44, Dave Korn wrote:
 On 29/10/2010 02:31, Ian Lance Taylor wrote:
 
 This implements an object file reader/writer which does everything
 required by LTO and gccgo.  The ELF code works.  I have not tested the
 Mach-O and COFF code at all beyond compiling it; I hope that somebody
 else can test those targets and fix them.

 With this patch, libelf is no longer needed.
 
   Almost, but not quite!  The attached patch switches the lto-plugin over to
 use the new objfile reader as well.

   Bootstrapped and tested all languages except java and ada on
 x86_64-unknown-linux-gnu, no regressions.  There are still a couple of bugs to
 iron out of the COFF-specific part of the objfile reader which I'll have fixed
 later today.
 
   OK for trunk (once the objfile changes have gone in)?

  As you'll see elsethread, I fixed the COFF problems.  This is the remaining
chunk of patch required to make the lto-plugin work on cygming targets.

gcc/ChangeLog:

* gcc.c (PLUGIN_PASSTHROUGH_SPEC): New macro factored out from
LINK_COMMAND_SPEC.
(LINK_COMMAND_SPEC): Use it.
(static_spec_functions[]): Add pass-through-libs entry.
(pass_through_libs_spec_func): Add related spec function.
* config/i386/cygming.h (PLUGIN_PASSTHROUGH_SPEC): Define.
* doc/tm.texi.in (PLUGIN_PASSTHROUGH_SPEC): Document.
(LINK_COMMAND_SPEC): Mention it.
* doc/tm.texi: Regenerate.
* doc/invoke.texi (pass-through-libs): Mention new spec function.

  Taking this for a bootstrap and test cycle now (on top of the objfile
changes).  Assuming no regressions, and one new PASS (the sole LTO test that
exercises -fuse-linker-plugin), and once all the other patches have gone in: OK?

cheers,
  DaveK

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi	(revision 166059)
+++ gcc/doc/tm.texi	(working copy)
@@ -406,6 +406,15 @@
 By default this is @code{%G %L %G}.
 @end defmac

+...@defmac PLUGIN_PASSTHROUGH_SPEC
+This macro is used as part of @code{LINK_COMMAND_SPEC} when the LTO plugin
+is in use.  It allows the system's standard libraries to be sent to the
+plugin as @option{-pass-through} plugin options, which causes them to be
+added at the end of the link when it may be necessary to resolve new
+undefined references generated as LTO expands builtins from the IR.  The
+default definition should suit ELF platforms.
+...@end defmac
+
 @defmac LINK_COMMAND_SPEC
 A C string constant giving the complete command line need to execute the
 linker.  When you do this, you will need to update your port each time a
@@ -413,7 +422,7 @@
 define this macro only if you need to completely redefine the command
 line for invoking the linker and there is no other way to accomplish
 the effect you need.  Overriding this macro may be avoidable by overriding
-...@code{link_gcc_c_sequence_spec} instead.
+...@code{link_gcc_c_sequence_spec} and/or @code{PLUGIN_PASSTHROUGH_SPEC} instead.
 @end defmac

 @defmac LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in	(revision 166059)
+++ gcc/doc/tm.texi.in	(working copy)
@@ -406,6 +406,15 @@
 By default this is @code{%G %L %G}.
 @end defmac

+...@defmac PLUGIN_PASSTHROUGH_SPEC
+This macro is used as part of @code{LINK_COMMAND_SPEC} when the LTO plugin
+is in use.  It allows the system's standard libraries to be sent to the
+plugin as @option{-pass-through} plugin options, which causes them to be
+added at the end of the link when it may be necessary to resolve new
+undefined references generated as LTO expands builtins from the IR.  The
+default definition should suit ELF platforms.
+...@end defmac
+
 @defmac LINK_COMMAND_SPEC
 A C string constant giving the complete command line need to execute the
 linker.  When you do this, you will need to update your port each time a
@@ -413,7 +422,7 @@
 define this macro only if you need to completely redefine the command
 line for invoking the linker and there is no other way to accomplish
 the effect you need.  Overriding this macro may be avoidable by overriding
-...@code{link_gcc_c_sequence_spec} instead.
+...@code{link_gcc_c_sequence_spec} and/or @code{PLUGIN_PASSTHROUGH_SPEC} instead.
 @end defmac

 @defmac LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 166059)
+++ gcc/doc/invoke.texi	(working copy)
@@ -9683,6 +9683,17 @@
 %:remove-outfile(-lm)
 @end smallexample

+...@item @code{pass-through-libs}
+The @code{pass-through-libs} spec function takes any number of arguments.  It
+finds any @option{-l} options and any non-options (which it assumes are the
+names of linker input files) and returns a result containing all the found
+arguments each prepended by @option{-plugin-opt=-pass-through=} and joined by
+spaces.  This list 

Re: Discussion about merging Go frontend

[Richard Henderson]

On 10/30/2010 01:16 AM, Dave Korn wrote:
 Do we really want to keep re-reading section data for every section
 lookup we do?  Can't we do this in objfile_open_read?
 
   It should only be necessary to do one section lookup per object file anyway.
  Keep extra data hanging around in memory in the backend just so that we can
 write algorithmically inefficient code in the client?  Seems like a bad
 tradeoff to me!

Uh, really?  I thought there were like a half-dozen lto sections...

   The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever need
 for LTO sections.

Perhaps, but there's an argument to the create_section function that
specifies the alignment.  If we only need 1-byte alignment that's fine,
but we should either assert that's true, omit the argument, or properly
support it.


r~

Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 18:57, Richard Henderson wrote:
 On 10/30/2010 01:16 AM, Dave Korn wrote:
 Do we really want to keep re-reading section data for every section
 lookup we do?  Can't we do this in objfile_open_read?
   It should only be necessary to do one section lookup per object file 
 anyway.
  Keep extra data hanging around in memory in the backend just so that we can
 write algorithmically inefficient code in the client?  Seems like a bad
 tradeoff to me!
 
 Uh, really?  I thought there were like a half-dozen lto sections...

  Which we iterate over just once, and record them all in a hash table from
the per-section callback, unless I've missed something.

   The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever 
 need
 for LTO sections.
 
 Perhaps, but there's an argument to the create_section function that
 specifies the alignment.  If we only need 1-byte alignment that's fine,
 but we should either assert that's true, omit the argument, or properly
 support it.

  Fair point.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Richard Henderson]

On 10/30/2010 11:37 AM, Dave Korn wrote:
 Uh, really?  I thought there were like a half-dozen lto sections...
 
   Which we iterate over just once, and record them all in a hash table from
 the per-section callback, unless I've missed something.

Oh, right.  Nevermind then.


r~

Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 19:24, Richard Henderson wrote:
 On 10/30/2010 11:37 AM, Dave Korn wrote:
 Uh, really?  I thought there were like a half-dozen lto sections...
   Which we iterate over just once, and record them all in a hash table from
 the per-section callback, unless I've missed something.
 
 Oh, right.  Nevermind then.
 
 
 r~

  It'd be worth putting a warning comment on the find_section (no s)
function saying that it's pretty inefficient and that it is best practice to
call find_sections just once and record details rather than make multiple
calls to find_section.  (Both lto FE and lto-plugin are already architected
that way.)

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 02:31, Ian Lance Taylor wrote:
 Dave Korn dave.korn.cygwin@  writes:
 
   What would be even nicer would be if we could share the same code-reader
 interface between lto and go (and the lto-plugin), thereby getting object
 format independence equally everywhere for no extra cost.
 
 How about this?

  That looks excellent, thank you!

 This implements an object file reader/writer which does everything
 required by LTO and gccgo.  The ELF code works.  I have not tested the
 Mach-O and COFF code at all beyond compiling it; I hope that somebody
 else can test those targets and fix them.

  I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be
available.

 With this patch, libelf is no longer needed.
 
 I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO
 testsuite.
 
 This patch puts the code in libiberty, but it could equally well go in
 gcc.  Anybody want to make an argument one way or another?

  Libiberty is better for sharing with lto-plugin, I think.  I sent a patch
that commoned out some of the COFF-reader code into gcc/, but I only put it
there because it was a single header file with no associated object file.  Now
there's actual code to be linked in, I think libiberty is a better choice than
lto-plugin trying to share .o files from the ../gcc/ objdir.

 Does the general interface look OK?
 
 This patch requires approval from the LTO maintainers.

  Also, I have a patch outstanding to COFF-ize the lto-plugin(*), so if we can
get an early OK in principle I'll get cracking on respinning it to use this
new interface.

cheers,
  DaveK
-- 
(*) - http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02176.html

Re: Discussion about merging Go frontend

[IainS]

On 29 Oct 2010, at 09:56, Dave Korn wrote:

This implements an object file reader/writer which does everything
required by LTO and gccgo.  The ELF code works.  I have not tested  
the

Mach-O and COFF code at all beyond compiling it; I hope that somebody
else can test those targets and fix them.


 I'm right here :) Can't help with Darwin but hopefully Jack/Iain  
will be

available.



I tried with 166058 on ppc-darwin9 (my other machines are tied up  
right now)


-flto fails on link with missing _main.
e.g:
Executing on host: /Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/xgcc -B/ 
Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/ c_lto_20081024_0.o  -

O0 -flto   -m32 -o gcc-dg-lto-20081024-21(timeout = 60)
Undefined symbols:
  _main, referenced from:
  start in crt1.10.5.o

-whopr ices with:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0,  
pfn=0x1d7ec lto_obj_add_section, data=0xb19c, err=0xb198)  
at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469

469   memcpy (name, sechdr + sectname_offset, MACH_O_NAME_LEN);
(gdb) bt
#0  0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0,  
pfn=0x1d7ec lto_obj_add_section, data=0xb19c, err=0xb198)  
at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469
#1  0x007f5dbc in objfile_find_sections (objfile=value temporarily  
unavailable, due to optimizations, pfn=value temporarily  
unavailable, due to optimizations, data=value temporarily  
unavailable, due to optimizations, err=value temporarily  
unavailable, due to optimizations) at /GCC/gcc-live-trunk/libiberty/ 
objfile.c:173
#2  0x0001dc60 in lto_obj_build_section_table (lto_file=value  
temporarily unavailable, due to optimizations) at /GCC/gcc-live-trunk/ 
gcc/lto/lto-objfile.c:270
#3  0x0001af80 in lto_read_all_file_options () at /GCC/gcc-live-trunk/ 
gcc/lto/lto.c:2052
#4  0x3960 in lto_post_options (pfilename=value temporarily  
unavailable, due to optimizations) at /GCC/gcc-live-trunk/gcc/lto/lto- 
lang.c:709
#5  0x004f0eec in toplev_main (argc=15, argv=Cannot access memory at  
address 0x1c

) at /GCC/gcc-live-trunk/gcc/toplev.c:1778
#6  0x1944 in start ()

if you need more analysis - ping me with what and I'll try and do sth  
-- or maybe Jack can help with a user on his machine.


cheers,
Iain

Re: Discussion about merging Go frontend

[Jack Howarth]

On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
 On 29/10/2010 02:31, Ian Lance Taylor wrote:
  Dave Korn dave.korn.cygwin@  writes:
  
What would be even nicer would be if we could share the same code-reader
  interface between lto and go (and the lto-plugin), thereby getting object
  format independence equally everywhere for no extra cost.
  
  How about this?
 
   That looks excellent, thank you!
 
  This implements an object file reader/writer which does everything
  required by LTO and gccgo.  The ELF code works.  I have not tested the
  Mach-O and COFF code at all beyond compiling it; I hope that somebody
  else can test those targets and fix them.
 
   I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be
 available.
 

Dave,
   Doesn't the go compiler require functional split stack support? Mike Stump
left me with the impression that split stack support would require additional
linker support on darwin.
   Jack

  With this patch, libelf is no longer needed.
  
  I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO
  testsuite.
  
  This patch puts the code in libiberty, but it could equally well go in
  gcc.  Anybody want to make an argument one way or another?
 
   Libiberty is better for sharing with lto-plugin, I think.  I sent a patch
 that commoned out some of the COFF-reader code into gcc/, but I only put it
 there because it was a single header file with no associated object file.  Now
 there's actual code to be linked in, I think libiberty is a better choice than
 lto-plugin trying to share .o files from the ../gcc/ objdir.
 
  Does the general interface look OK?
  
  This patch requires approval from the LTO maintainers.
 
   Also, I have a patch outstanding to COFF-ize the lto-plugin(*), so if we can
 get an early OK in principle I'll get cracking on respinning it to use this
 new interface.
 
 cheers,
   DaveK
 -- 
 (*) - http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02176.html

Re: Discussion about merging Go frontend

[Richard Guenther]

On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor i...@google.com wrote:
 Dave Korn dave.korn.cyg...@gmail.com writes:

   What would be even nicer would be if we could share the same code-reader
 interface between lto and go (and the lto-plugin), thereby getting object
 format independence equally everywhere for no extra cost.

 How about this?

 This implements an object file reader/writer which does everything
 required by LTO and gccgo.  The ELF code works.  I have not tested the
 Mach-O and COFF code at all beyond compiling it; I hope that somebody
 else can test those targets and fix them.

 With this patch, libelf is no longer needed.

 I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO
 testsuite.

 This patch puts the code in libiberty, but it could equally well go in
 gcc.  Anybody want to make an argument one way or another?

 Does the general interface look OK?

 This patch requires approval from the LTO maintainers.  I don't need
 approval for the libiberty changes (if the code stays in libiberty) but
 of course I would appreciate it if somebody could look it over.  I think
 the configure and Makefile changes are sufficiently obvious given the
 other changes as to not require approval.

 If this patch is accepted, then gccgo will not require elfcpp.

Nice!

The LTO changes are ok (I suppose you'll be around in helping people
debug eventual problems).

Richard.

 Ian


 include/ChangeLog:

 2010-10-28  Ian Lance Taylor  i...@google.com

        * objfile.h: New file.

 libiberty/ChangeLog:

 2010-10-28  Ian Lance Taylor  i...@google.com

        * objfile.c: New file.
        * objfile-common.h: New file.
        * objfile-elf.c: New file.
        * objfile-mach-o.c: New file.
        * objfile-coff.c: New file.
        * configure.ac: Add AC_TYPE_SSIZE_T.
        * Makefile.in: Rebuild dependencies.
        (CFILES): Add objfile.c, objfile-coff, objfile-elf.c,
        objfile-mach-o.c.
        (REQUIRED_OFILES): Add corresponding object files.
        * configure: Rebuild.
        * config.in: Rebuild.

 gcc/ChangeLog:

 2010-10-28  Ian Lance Taylor  i...@google.com

        * configure.ac: Remove elf_getshdrstrndx test.  Don't substitute
        LTO_BINARY_READER or LTO_USE_LIBELF.  Remove LIBELFLIBS and
        LIBELFINC.  Remove HAVE_libelf.
        * gcc/config.gcc: Don't set lto_binary_reader.
        * gcc/Makefile.in (LIBELFLIBS, LIBELFINC): Remove variables.
        (LTO_BINARY_READER, LTO_USE_LIBELF): Remove variables.
        (LIBS): Remove $(LIBELFLIBS).
        (INCLUDES): Remove $(LIBELFINC).
        * doc/install.texi (Prerequisites): Remove libelf paragraphs.
        (Configuration): Mention --disable-lto.  Remove --with-libelf
        paragraph.
        * configure: Rebuild.
        * config.in: Rebuild.

 gcc/lto/ChangeLog:

 2010-10-28  Ian Lance Taylor  i...@google.com

        * lto-objfile.c: New file.
        * lto-elf.c: Remove file.
        * lto-macho.c: Remove file.
        * lto-macho.h: Remove file.
        * lto-coff.c: Remove file.
        * lto-coff.h: Remove file.
        * Make-lang.in (LTO_OBJS): Change lto/$(LTO_BINARY_READER).o to
        lto/lto-objfile.o.
        ($(LTO_EXE)): Remove $(LTO_USE_LIBELF)
        (lto/lto-objfile.o): New target.
        (lto/lto-elf.o, lto/lto-coff.o, lto/lto-macho.o): Remove targets.

 ./ChangeLog:

 2010-10-28  Ian Lance Taylor  i...@google.com

        * configure.ac: Don't set default_enable_lto.  Remove libelf tests.
        * configure: Rebuild.

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 14:31, Richard Guenther wrote:
 On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor i...@google.com wrote:

 This patch requires approval from the LTO maintainers.  I don't need
 approval for the libiberty changes (if the code stays in libiberty) but
 of course I would appreciate it if somebody could look it over.  I think
 the configure and Makefile changes are sufficiently obvious given the
 other changes as to not require approval.

 If this patch is accepted, then gccgo will not require elfcpp.
 
 Nice!
 
 The LTO changes are ok (I suppose you'll be around in helping people
 debug eventual problems).

  I'll start work on porting the lto-plugin to use the new interface.  It'll
subsume my plugin-for-coff patch.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 14:18, Jack Howarth wrote:
 On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
 On 29/10/2010 02:31, Ian Lance Taylor wrote:
 Dave Korn dave.korn.cygwin@  writes:

   What would be even nicer would be if we could share the same code-reader
 interface between lto and go (and the lto-plugin), thereby getting object
 format independence equally everywhere for no extra cost.
 How about this?
   That looks excellent, thank you!

 This implements an object file reader/writer which does everything
 required by LTO and gccgo.  The ELF code works.  I have not tested the
 Mach-O and COFF code at all beyond compiling it; I hope that somebody
 else can test those targets and fix them.
   I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be
 available.

 
 Dave,
Doesn't the go compiler require functional split stack support? 

  Ian will have to answer that, I don't know.

 Mike Stump
 left me with the impression that split stack support would require additional
 linker support on darwin.

  Well, this also affects LTO, since it refactors the object file support
underlying that.  As Iain has discovered...

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Jack Howarth howa...@bromo.med.uc.edu writes:

Doesn't the go compiler require functional split stack support? Mike Stump
 left me with the impression that split stack support would require additional
 linker support on darwin.

The Go compiler can work without split stack support.  The effect is
that you are limited in the number of goroutines you can create,
particularly on a 32-bit system.  And you are also limited in the depth
of recursion and size of local variables you can create.  But you can
write working Go programs.

The objfile patch, however, is not really about Go, although gccgo will
use it.  It's really about LTO.  If it works for LTO, it will work for
gccgo.

Ian

Re: Discussion about merging Go frontend

[Jack Howarth]

On Fri, Oct 29, 2010 at 06:49:51AM -0700, Ian Lance Taylor wrote:
 Jack Howarth howa...@bromo.med.uc.edu writes:
 
 Doesn't the go compiler require functional split stack support? Mike 
  Stump
  left me with the impression that split stack support would require 
  additional
  linker support on darwin.
 
 The Go compiler can work without split stack support.  The effect is
 that you are limited in the number of goroutines you can create,
 particularly on a 32-bit system.  And you are also limited in the depth
 of recursion and size of local variables you can create.  But you can
 write working Go programs.

Ian,
   Is split stack support unique to the go compiler or might it eventually
be leveraged in the other compilers as well? We could submit a radar for
the addition of split stack support for the linker in Xcode 4.0 or later
but it would helpful if the eventual usage was greater than just the go
compiler.
 Jack

 
 The objfile patch, however, is not really about Go, although gccgo will
 use it.  It's really about LTO.  If it works for LTO, it will work for
 gccgo.
 
 Ian

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/28/2010 6:31 PM, Ian Lance Taylor wrote:

 This patch requires approval from the LTO maintainers.  I don't need
 approval for the libiberty changes (if the code stays in libiberty) but
 of course I would appreciate it if somebody could look it over.  I think
 the configure and Makefile changes are sufficiently obvious given the
 other changes as to not require approval.

This all looks good to me, and seems like a reasonable solution.  I
think libiberty is as good a place as any for the routines, FWIW.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Jack Howarth howa...@bromo.med.uc.edu writes:

Is split stack support unique to the go compiler or might it eventually
 be leveraged in the other compilers as well? We could submit a radar for
 the addition of split stack support for the linker in Xcode 4.0 or later
 but it would helpful if the eventual usage was greater than just the go
 compiler.

Split stack support is now in mainline and is available for any language
via the -fsplit-stack option.  The only thing unique to the Go frontend
is that the Go frontend turns it on by default.

Using it on Darwin will require some porting work of the assembly code
in libgcc, which currently uses ELF pseudo-ops.  Object files which are
compiled with -fsplit-stack need to be marked in some way.  What the
linker needs to do is frob functions in object files compiled with
-fsplit-stack which call functoins defined in object files compiled
without -fsplit-stack.

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Paolo Bonzini bonz...@gnu.org writes:

 On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
 configure.ac
Add libgo.  If building Go, build C++ as a boot language.

 Can you generalize this using something in gcc/go/config-lang.in?

I have now done this on the gccgo branch.  If language X's
config-lang.in sets the shell variable lang_requires_boot_language, then
if X is enabled all those languages are built during stage 1.

Ian

Re: Discussion about merging Go frontend

[H.J. Lu]

On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor i...@google.com wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
 configure.ac
    Add libgo.  If building Go, build C++ as a boot language.

 Can you generalize this using something in gcc/go/config-lang.in?

 I have now done this on the gccgo branch.  If language X's
 config-lang.in sets the shell variable lang_requires_boot_language, then
 if X is enabled all those languages are built during stage 1.


Don't we have boot_language for this purpose?


-- 
H.J.

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

H.J. Lu hjl.to...@gmail.com writes:

 On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor i...@google.com wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
 configure.ac
    Add libgo.  If building Go, build C++ as a boot language.

 Can you generalize this using something in gcc/go/config-lang.in?

 I have now done this on the gccgo branch.  If language X's
 config-lang.in sets the shell variable lang_requires_boot_language, then
 if X is enabled all those languages are built during stage 1.


 Don't we have boot_language for this purpose?

No, boot_language serves a different purpose.  It says that the language
itself should be built during stage 1.  What I need for Go is to say
that C++ should be built during stage 1.  That is, boot_language is a
yes or no value.  I have added lang_requires_boot_language, which takes
a list of languages.  It is similar to lang_requires, except that it
specifically builds the specified languages during stage 1.

Ian

Re: Discussion about merging Go frontend

[Richard Henderson]

 +extern objfile_read *
 +objfile_open_read (int descriptor, off_t offset, const char *segment_name,
 +const char **errmsg, int *err);
...
 +extern objfile_write *
 +objfile_start_write (objfile_attributes *ATTRS, const char *segment_name,
 +  const char **errmsg, int *err);

Mismatch in naming conventions?  I like the use of release
to clearly indicate non-closure of the FD.

 +  shdr_size = (cl == ELFCLASS32
 +? sizeof (Elf32_External_Shdr)
 +: sizeof (Elf64_External_Shdr));
 +  memset (buf, 0, shdr_size);

Constant size memset is easier to optimize.  You might as well
zero all of BUF, even if we're not going to use it all.  The
slop between 32 and 64 is minimal.

 +  if (!objfile_internal_read (objfile-descriptor,
 +   objfile-offset + eor-shoff + shdr_size,
 +   shdrs,
 +   shdr_size * (shnum - 1),
 +   errmsg, err))

Do we really want to keep re-reading section data for every section
lookup we do?  Can't we do this in objfile_open_read?

 +  set_32 (hdr + offsetof (struct external_scnhdr, s_flags),
 +   (STYP_DATA | IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE
 +| IMAGE_SCN_MEM_SHARED | IMAGE_SCN_MEM_READ));

You're not recording alignment in the coff object file?
IMAGE_SCN_ALIGN_NBYTES, 1 = N = 8192, are all defined
with a simple function in that nibble.


r~

Re: Discussion about merging Go frontend

[H.J. Lu]

On Fri, Oct 29, 2010 at 4:39 PM, Ian Lance Taylor i...@google.com wrote:
 H.J. Lu hjl.to...@gmail.com writes:

 On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor i...@google.com wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
 configure.ac
    Add libgo.  If building Go, build C++ as a boot language.

 Can you generalize this using something in gcc/go/config-lang.in?

 I have now done this on the gccgo branch.  If language X's
 config-lang.in sets the shell variable lang_requires_boot_language, then
 if X is enabled all those languages are built during stage 1.


 Don't we have boot_language for this purpose?

 No, boot_language serves a different purpose.  It says that the language
 itself should be built during stage 1.  What I need for Go is to say
 that C++ should be built during stage 1.  That is, boot_language is a
 yes or no value.  I have added lang_requires_boot_language, which takes


Will put

if [ Go is enabled ]; then
  boot_language=yes
fi

in cp/config-lang.in work?


-- 
H.J.

Re: Discussion about merging Go frontend

[Joseph S. Myers]

On Mon, 25 Oct 2010, Mark Mitchell wrote:

 On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote:
 
  By the way, is there some necessity in accomplishing this by means of
  a linked library, as opposed to via a spawned objcopy process?

(elfcpp isn't a *linked* library; it's a C++ template library consisting 
entirely of headers, with no makefile code or .o or .a files.)

 Probably none in theory, but it certainly seems messy and likely to be
 slow in practice.  Is there a reason that this would be desirable?

Well, slow on hosts where process creation is slow (just like the separate 
gcc/cc1/as/collect2/ld/lto-wrapper/... processes).  The separate process 
design was probably based on process creation being fast - although 
separate processes do have security and potentially parallelism advantages 
over using libraries for everything.  (It probably wouldn't be hard to 
support linking more of the separate programs into one for hosts where 
this helps; cf. the past MVS discussions.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/26/2010 10:41 AM, Joseph S. Myers wrote:

 Well, slow on hosts where process creation is slow (just like the separate 
 gcc/cc1/as/collect2/ld/lto-wrapper/... processes).  The separate process 
 design was probably based on process creation being fast

A lot of this is also historical; gcc/cc1/as/ld mirror typical UNIX
compilers of the era at which GCC was built.  collect2 was presumably
necessary because of dependence on proprietary ld; if we could assume
GNU ld (or GOLD) everywhere, we could fold that functionality directly
into the linker.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Mark Mitchell m...@codesourcery.com writes:

 A lot of this is also historical; gcc/cc1/as/ld mirror typical UNIX
 compilers of the era at which GCC was built.  collect2 was presumably
 necessary because of dependence on proprietary ld; if we could assume
 GNU ld (or GOLD) everywhere, we could fold that functionality directly
 into the linker.

For what it's worth, all of the functionality except for -frepo is
already folded into both.  And I suspect that -frepo support could be
handled via a linker plugin.

Ian

Re: Discussion about merging Go frontend

[Andi Kleen]

On Tue, Oct 26, 2010 at 11:51:20AM -0400, Mark Mitchell wrote:
 On 10/26/2010 10:41 AM, Joseph S. Myers wrote:
 
  Well, slow on hosts where process creation is slow (just like the separate 
  gcc/cc1/as/collect2/ld/lto-wrapper/... processes).  The separate process 
  design was probably based on process creation being fast
 
 A lot of this is also historical; gcc/cc1/as/ld mirror typical UNIX
 compilers of the era at which GCC was built.  collect2 was presumably
 necessary because of dependence on proprietary ld; if we could assume
 GNU ld (or GOLD) everywhere, we could fold that functionality directly
 into the linker.

Right now it is definitely required to set up all the LTO 
environment for the backend linker.

However that could probably move into the gcc driver.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:

 It's hard for me to believe that BFD is the correct answer.  It's poorly
 designed for the kinds of things the compiler needs to do.  Any program
 which links against BFD effectively links in the GNU linker.

It sounded from your mail like all the compiler needs to do is to read
the binary contents of a named section.  Isn't that something that BFD
does well?

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Mark Mitchell m...@codesourcery.com writes:

 On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:

 It's hard for me to believe that BFD is the correct answer.  It's poorly
 designed for the kinds of things the compiler needs to do.  Any program
 which links against BFD effectively links in the GNU linker.

 It sounded from your mail like all the compiler needs to do is to read
 the binary contents of a named section.  Isn't that something that BFD
 does well?

BFD will get the job done.  But I don't think it's a good choice for
releasing a program like gcc.

BFD is in effect an internal library for the linker and the GNU
binutils, and it's also used by the assembler.  It doesn't really
maintain source compatibility across releases, and it definitely doesn't
maintain binary compatibility.  As I mentioned above, when you link
against BFD you effectively pull in the linker.

Reading a section from an object file is not hard.  Linking against BFD
to do it is massive overkill.  If we were already linking against BFD,
then sure.  But introducing BFD for this will give us and the binutils
developers some long-term maintenance pain for limited reward.

At least, that is how I see it.

Ian

Re: Discussion about merging Go frontend

[Andrew Pinski]

On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote:
 At least, that is how I see it.

Why not require libelf just like for LTO?  That seems like a time to
reduce what we depend on.  For an example if we compile with lto and
go, GCC will use two different elf libraries.  This seems dumb really.

Thanks,
Andrew Pinski

Re: Discussion about merging Go frontend

[Andi Kleen]

Andrew Pinski pins...@gmail.com writes:

 On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote:
 At least, that is how I see it.

 Why not require libelf just like for LTO?  That seems like a time to
 reduce what we depend on.  For an example if we compile with lto and
 go, GCC will use two different elf libraries.  This seems dumb really.

libelf is rather awkward and has different implementations with
different bugs and also usually needs to be installed explicitely on
Linux.

It would be better to make LTO use Ian's library (but then it's C++ I
believe, not C)

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.

Re: Discussion about merging Go frontend

[Dave Korn]

On 25/10/2010 19:43, Andi Kleen wrote:
 Andrew Pinski pins...@gmail.com writes:
 
 On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote:
 At least, that is how I see it.
 Why not require libelf just like for LTO?  That seems like a time to
 reduce what we depend on.  For an example if we compile with lto and
 go, GCC will use two different elf libraries.  This seems dumb really.
 
 libelf is rather awkward and has different implementations with
 different bugs and also usually needs to be installed explicitely on
 Linux.
 
 It would be better to make LTO use Ian's library (but then it's C++ I
 believe, not C)
 
 -Andi

  What would be even nicer would be if we could share the same code-reader
interface between lto and go (and the lto-plugin), thereby getting object
format independence equally everywhere for no extra cost.

  That could be orthogonal to plugging elfcpp into the role currently occupied
by libelf in that reader.

  (As to needing c++, that's just a matter of enabling c++ as a stage1
language and living with the minor limitation that go can't be a stage1
language unless you already have an installed c++ compiler, no?)

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/25/2010 7:01 PM, Dave Korn wrote:

   What would be even nicer would be if we could share the same code-reader
 interface between lto and go (and the lto-plugin), thereby getting object
 format independence equally everywhere for no extra cost.
 
   That could be orthogonal to plugging elfcpp into the role currently occupied
 by libelf in that reader.

I think it's reasonable to argue that GCC should, going forward, be an
ELF-only toolchain -- with postprocessing tools for generating PE/COFF,
Symbian DLLs, Mach-O or what have you.  But, we haven't made that
decision.  So, I don't think we should get there by half-measures.

Either we should decide that's what we want to do, or we should try to
keep the compiler independent of the object file format -- as we have up
until now.  I understand Ian's distaste for BFD, but it is the
format-independent object file reader we have, so it seems a natural
choice.  And libelf, which we already rely on seems more natural than
elfcpp, if we're willing to go ELF-only -- unless we're going to replace
the use of libelf in LTO with elfcpp as well.

In any case, I think we should avoid a single compiler build requiring
multiple object-file reading libraries.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Dave Korn]

On 25/10/2010 23:49, Mark Mitchell wrote:
 On 10/25/2010 7:01 PM, Dave Korn wrote:
 
   What would be even nicer would be if we could share the same code-reader
 interface between lto and go (and the lto-plugin), thereby getting object
 format independence equally everywhere for no extra cost.

   That could be orthogonal to plugging elfcpp into the role currently 
 occupied
 by libelf in that reader.
 
 I think it's reasonable to argue that GCC should, going forward, be an
 ELF-only toolchain -- with postprocessing tools for generating PE/COFF,
 Symbian DLLs, Mach-O or what have you.  But, we haven't made that
 decision.  So, I don't think we should get there by half-measures.

  I'll probably be on the other side of that argument, when it comes, for a
combination of political and engineering reasons.  But, like you say, let's
not get side-tracked.

 Either we should decide that's what we want to do, or we should try to
 keep the compiler independent of the object file format -- as we have up
 until now.

  Ian could fairly point out that LTO was accepted into the compiler before it
was format-agnostic.  I would counter that, until such a decision as you
contemplate is actually made, it would have been preferable if it was
format-agnostic from the start.  However, we are where we are, and don't want
to let the perfect be the enemy of the good.

 I understand Ian's distaste for BFD, but it is the
 format-independent object file reader we have, so it seems a natural
 choice.  And libelf, which we already rely on seems more natural than
 elfcpp, if we're willing to go ELF-only -- unless we're going to replace
 the use of libelf in LTO with elfcpp as well.

  Well, TBH, I suggested BFD as a devil's-advocate position.  It does indeed
work, but it is kind of clunky, and top-heavy for what the compiler's
requirements actually amount to.

  From Ian's description, gccgo has the exact same requirements as LTO: be
able to parse an object file, get a list of sections, and get raw binary
access to the data contained within a named section.  This is a problem which
we already have solved.  (And indeed LTO's solution also has object writing
capabilities that gccgo doesn't need.)

 In any case, I think we should avoid a single compiler build requiring
 multiple object-file reading libraries.

  Code re-use FTW!  As far as I can see, we're not going to need anything
significantly more complex than what the LTO-FE already needs, until and
unless we get to a point of integrating the (assembler and) linker into the
compiler itself, which is a long way off for now.

  That being the case, I think a reasonable plan would be:

- integrate gccgo, with elfcpp
- then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all
the FEs can share it
- then convert it to use elfcpp (with a bit of file I/O added) and stop using
libelf altogether
- then switch gccgo over to using it

... of which I think all but the first step would even be stage3-friendly.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/25/2010 10:07 PM, Dave Korn wrote:

 - integrate gccgo, with elfcpp
 - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all
 the FEs can share it
 - then convert it to use elfcpp (with a bit of file I/O added) and stop using
 libelf altogether
 - then switch gccgo over to using it

I think that's a reasonable plan.  It makes things no less object-file
netural than they are now, which is OK.  (And, before someone else
points it out, I believe it was I who started using libelf in the LTO
prototype, so I know full well how we got here!)  I certainly have no
problem with using elfcpp over libelf.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Frank Ch. Eigler]

Dave Korn dave.korn.cyg...@gmail.com writes:

 [...]  From Ian's description, gccgo has the exact same requirements
 as LTO: be able to parse an object file, get a list of sections, and
 get raw binary access to the data contained within a named section.
 This is a problem which we already have solved.  (And indeed LTO's
 solution also has object writing capabilities that gccgo doesn't
 need.)  [...]

By the way, is there some necessity in accomplishing this by means of
a linked library, as opposed to via a spawned objcopy process?

- FChE

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote:

 By the way, is there some necessity in accomplishing this by means of
 a linked library, as opposed to via a spawned objcopy process?

Probably none in theory, but it certainly seems messy and likely to be
slow in practice.  Is there a reason that this would be desirable?

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Frank Ch. Eigler]

Hi -

  By the way, is there some necessity in accomplishing this by means of
  a linked library, as opposed to via a spawned objcopy process?

 Probably none in theory, but it certainly seems messy and likely to
 be slow in practice.

Yes, maybe.

 Is there a reason that this would be desirable?

It would seem to moot the present discussion about competing elf
consumer libraries.  none of the above is a possible answer.

- FChE

Re: Discussion about merging Go frontend

[Mark Mitchell]

On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote:

 It would seem to moot the present discussion about competing elf
 consumer libraries.  none of the above is a possible answer.

True.  It seems that LTO and Go need a very simple interface; presumably
we can abstract that in the compiler and then we can implement that
interface as we please.  I agree that a fallback to an external objcopy
is plausible, as is linking with BFD.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Discussion about merging Go frontend

[Joseph S. Myers]

On Sat, 23 Oct 2010, Ian Lance Taylor wrote:

 affect other languages.  The only thing I hope to clean up further
 before the merge is additional separation between the Go frontend proper
 and the gcc-specific interface.  I'm not going to have time to do the
 full planned separation, which I will continue to work on, but I hope to
 have the proper framework in place for future work.

Will the front end use its own text domain for i18n of messages, or the 
gcc domain?  Whatever the answer, do you need changes to po/exgettext or 
similar to cause all the messages to be properly extracted?

 There are three new source code directories: gcc/go, libgo, and elfcpp.
 The last is currently part of the src repository, where it is used by
 gold.  I propose moving the master copy of elfcpp to gcc, and handling
 it like libiberty.

How is elfcpp used?  Is this front end in some way restricted to ELF 
targets, or more functional with them?  (In general, to what extent are 
the front end and library portable to different targets - how much work, 
if any, is needed to get them building and working for a new target 
(architecture or OS)?  Would the sort of target changes needed be risky 
for Stage 3?  What about host portability?)

 The following other files are changed:

You don't mention documentation.  Does the front end have its own manual?  
Whether or not it does, the new-front-end checklist (Front End in 
sourcebuild.texi) lists places in the documentation that need updating for 
a new front end (install.texi, contrib.texi, frontends.texi, 
standards.texi, invoke.texi, sourcebuild.texi - plus web page etc. updates 
for merging to trunk).

 gcc/opts.c
 gcc/toplev.c
 gcc/debug.h
 gcc/flag-types.h
 gcc/c-family/c-lex.c
 gcc/Makefile.in
   Add support for -ggo, used when building runtime library.

Note that all -g* options are also handled in a case statement in 
java/jvspec.c, though that might well better be handled through specs, and 
I don't know if -ggo makes sense at all for Java.

I think appropriate coding standards documentation for this front end is 
needed.  Possibly in the form of a description of how the coding standards 
differ from the general conventions for C++ in existing parts of GCC at 
http://gcc.gnu.org/wiki/CppConventions, though those would need merging 
into codingconventions.html before being used as a basis for conventions 
actually used on GCC trunk.

The front end's langhooks don't seem to have been updated for the 
separation of the init_options and init_options_struct hooks.

I presume you will be posting the front end and other changes for review 
(or, I suppose, given the size of the changes, explicitly stating that you 
propose for review the diffs between particular revisions of trunk and a 
branch given by a particular svn diff command) as indicated in 
http://gcc.gnu.org/ml/gcc/2010-01/msg00504.html.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Discussion about merging Go frontend

[Dave Korn]

On 24/10/2010 06:40, Ian Lance Taylor wrote:

 There are three new source code directories: gcc/go, libgo, and elfcpp.
 The last is currently part of the src repository, where it is used by
 gold.  I propose moving the master copy of elfcpp to gcc, and handling
 it like libiberty.

  What about non-ELF platforms?  Will go not be buildable for them?

  This is the second ELF-specific object reader library getting dragged into
the compiler build.  Maybe we should give some consideration to just merging
the whole of src/ and gcc/ and be done with it, so that all the non-ELF
targets can get BFD support?

cheers,
  DaveK

Re: Discussion about merging Go frontend

[H.J. Lu]

On Sat, Oct 23, 2010 at 10:40 PM, Ian Lance Taylor i...@google.com wrote:
 The Go frontend was approved for inclusion with gcc by the steering
 committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html .

 Assuming it is OK with the release managers, I would like to get it into
 the gcc 4.6 release.  I have been running behind my intended schedule,
 for which I apologize.  However, the code is almost ready to merge, in
 the sense that the only remaining changes are Go specific and should not
 affect other languages.  The only thing I hope to clean up further
 before the merge is additional separation between the Go frontend proper
 and the gcc-specific interface.  I'm not going to have time to do the
 full planned separation, which I will continue to work on, but I hope to
 have the proper framework in place for future work.


Does Go depend on split stack? There are at least 2 split stack bugs
open for x86 target.


H.J.

Re: Discussion about merging Go frontend

[Paolo Bonzini]

On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:

configure.ac
   Add libgo.  If building Go, build C++ as a boot language.


Can you generalize this using something in gcc/go/config-lang.in?

Paolo

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Dave Korn dave.korn.cyg...@gmail.com writes:

 On 24/10/2010 06:40, Ian Lance Taylor wrote:

 There are three new source code directories: gcc/go, libgo, and elfcpp.
 The last is currently part of the src repository, where it is used by
 gold.  I propose moving the master copy of elfcpp to gcc, and handling
 it like libiberty.

   What about non-ELF platforms?  Will go not be buildable for them?

At present, gccgo is most conveniently used on ELF platforms.  The issue
is how to handle importing a package.  All Go code lives in a package.
When you compile a package, gccgo puts export data into the object file,
in the .go_export section.  This is done using the usual get_section
function.  Support for named sections is required at present, but
nothing else.

However, when you import a package, gccgo needs to locate that data.  In
gccgo I used the elfcpp library to read the data out of an ELF file.
Gccgo can also read the data out of a plain text file, so it can work
with a non-ELF format although some other mechanism, such as objcopy,
would be needed to extract the data from the .go_export section into a
text file.

Of course it would be best if gccgo simply learned how to read other
object file formats.  It would not be particularly difficult, but I
don't have any current plans for working on it.

The dependence on elfcpp is not particularly deep.  It's confined to a
single file, import-elf.cc.  On the other hand elfcpp is not very large,
4500 lines.


   This is the second ELF-specific object reader library getting dragged into
 the compiler build.  Maybe we should give some consideration to just merging
 the whole of src/ and gcc/ and be done with it, so that all the non-ELF
 targets can get BFD support?

It's hard for me to believe that BFD is the correct answer.  It's poorly
designed for the kinds of things the compiler needs to do.  Any program
which links against BFD effectively links in the GNU linker.

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

H.J. Lu hjl.to...@gmail.com writes:

 Does Go depend on split stack?

Yes.

 There are at least 2 split stack bugs
 open for x86 target.

Yes, I saw those but I have not had time to look at them.  I will.

Ian

Re: Discussion about merging Go frontend

[Andrew Pinski]

Why can't gccgo handle this like gnu objective-c runtime handles this?  
Why does it need to be designed such it is in a specific section  
instead of registering at runtime?  Seems like this a bad design of  
registering modules really.


On Oct 24, 2010, at 7:52 PM, Ian Lance Taylor i...@google.com wrote:


Dave Korn dave.korn.cyg...@gmail.com writes:


On 24/10/2010 06:40, Ian Lance Taylor wrote:

There are three new source code directories: gcc/go, libgo, and  
elfcpp.
The last is currently part of the src repository, where it is used  
by
gold.  I propose moving the master copy of elfcpp to gcc, and  
handling

it like libiberty.


 What about non-ELF platforms?  Will go not be buildable for them?


At present, gccgo is most conveniently used on ELF platforms.  The  
issue

is how to handle importing a package.  All Go code lives in a package.
When you compile a package, gccgo puts export data into the object  
file,

in the .go_export section.  This is done using the usual get_section
function.  Support for named sections is required at present, but
nothing else.

However, when you import a package, gccgo needs to locate that  
data.  In

gccgo I used the elfcpp library to read the data out of an ELF file.
Gccgo can also read the data out of a plain text file, so it can work
with a non-ELF format although some other mechanism, such as objcopy,
would be needed to extract the data from the .go_export section into a
text file.

Of course it would be best if gccgo simply learned how to read other
object file formats.  It would not be particularly difficult, but I
don't have any current plans for working on it.

The dependence on elfcpp is not particularly deep.  It's confined to a
single file, import-elf.cc.  On the other hand elfcpp is not very  
large,

4500 lines.


 This is the second ELF-specific object reader library getting  
dragged into
the compiler build.  Maybe we should give some consideration to  
just merging
the whole of src/ and gcc/ and be done with it, so that all the non- 
ELF

targets can get BFD support?


It's hard for me to believe that BFD is the correct answer.  It's  
poorly
designed for the kinds of things the compiler needs to do.  Any  
program

which links against BFD effectively links in the GNU linker.

Ian

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Andrew Pinski pins...@gmail.com writes:

 Why can't gccgo handle this like gnu objective-c runtime handles this?
 Why does it need to be designed such it is in a specific section
 instead of registering at runtime?  Seems like this a bad design of
 registering modules really.

This is data generated by the compiler when it compiles a package and
read by the compiler when it imports a package.

There is nothing happening at runtime here.

Ian