On Mon, Jun 4, 2012 at 2:40 PM, Steven Bosscher <stevenb....@gmail.com> wrote:
> Hello,
>
> In a perfect world, front ends would not be writing out anything to
> the assembler output. GCC is not part of this perfect world, at least
> not yet. It should be possible, with a little help from front-end
> maintainers, especially for Ada and ObjC and someone knowledgeable of
> PCH, to enforce a rule that a front end must not #include output.h.
>
> A part of the compiler that writes to the assembler output has to
> include output.h or use one of the functions prototyped there.
> Therefore I have tried to remove #includes of output.h last week. I am
> stuck on 9 files that still have to include output.h for the following
> symbols:
>
> 1. assemble_string
> 2. get_section
> 3. switch_to_section
> 4. have_global_bss_p
> 5. first_global_object_name
> 6. asm_out_file
>
> The uses of these symbols are in the following files:
>
> assemble_string / get_section / switch_to_section:
> go/go-backend.c: assemble_string (bytes, size);
> go/go-backend.c: sec = get_section (GO_EXPORT_SECTION_NAME,
> SECTION_DEBUG, NULL);
> go/go-backend.c: switch_to_section (sec);
> java/class.c: switch_to_section (get_section (buf, flags, NULL));
> java/class.c: switch_to_section (get_section (buf, flags, NULL));
>
> I am not sure how to fix this. I think it could be fixed by having a
> version of build_constant_desc that puts the data in a specific
> section while wrapping up global variables in varasm. The above code
> means that these front ends do not work (and maybe are not supposed to
> work) with LTO. That is something that IMHO should be documented
> somewhere.
Don't we have attribute((section("..."))) anyways, so a mechanism for this
already?
>
> have_global_bss_p:
> cp/decl.c: && !have_global_bss_p ())
> ada/gcc-interface/utils.c: && !have_global_bss_p ())
>
> I don't even know what this is. Help welcome. :-)
Looks like premature optimization to me, better done in varpool_finalize_decl?
> first_global_object_name:
> ada/gcc-interface/trans.c: first_global_object_name = ggc_strdup
> (IDENTIFIER_POINTER (t));
> ada/gcc-interface/utils.c: ASM_FORMAT_PRIVATE_NAME (label,
> first_global_object_name, 0);
>
> This comes from here:
>
> /* Declare the name of the compilation unit as the first global
> name in order to make the middle-end fully deterministic. */
> t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
> first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
>
> Only the Ada front end has code like this. The other front ends set
> first_global_object_name via notice_global_symbol (which is called
> from varpool_finalize_decl and a few other places). It seems like a
> good idea to me, to make first_global_object_name deterministic.
> Perhaps it should be set to the top level translation unit by all
> front ends? That would also simplify notice_global_symbol and prevent
> it from accessing/creating DECL_RTL early.
>
>
> user_label_prefix:
> c-family/c-cppbuiltin.c: builtin_define_with_value
> ("__USER_LABEL_PREFIX__", user_label_prefix, 0);
>
> Because user_label_prefix is defined in toplev.c, I think its global
> decl should be moved from output.h to toplev.h.
Sounds reasonable.
>
> asm_out_file for ASM_OUTPUT_IDENT:
> c-family/c-lex.c:#include "output.h" /* for asm_out_file */
> c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
> *) cstr.text);
> ada/gcc-interface/trans.c: (asm_out_file,
>
> I am not sure how to fix this. Maybe also write this out via a version
> of build_constant_desc that puts the data in a specific section (that
> would be required for MIPS' version of ASM_OUTPUT_IDENT).
Hm. The docs for -fno-ident say
@item -fno-ident
@opindex fno-ident
Ignore the @samp{#ident} directive.
And the CPP docs:
@findex #ident
@findex #sccs
The @samp{#ident} directive takes one argument, a string constant. On
some systems, that string constant is copied into a special segment of
the object file. On other systems, the directive is ignored. The
@samp{#sccs} directive is a synonym for @samp{#ident}.
I suppose make ASM_OUTPUT_IDENT a target hook instead.
Richard.
>
> a@item -fno-ident
@opindex fno-ident
Ignore the @samp{#ident} directive.
sm_out_file for PCH:
> c-family/c-pch.c:#include "output.h" /* for asm_out_file */
> c-family/c-pch.c: fprintf (asm_out_file, "%s ", ASM_COMMENT_START);
> c-family/c-pch.c: c_common_print_pch_checksum (asm_out_file);
> c-family/c-pch.c: fputc ('\n', asm_out_file);
> c-family/c-pch.c: asm_file_startpos = ftell (asm_out_file);
> c-family/c-pch.c: asm_file_end = ftell (asm_out_file);
> c-family/c-pch.c: if (fseek (asm_out_file, asm_file_startpos, SEEK_SET) != 0)
> c-family/c-pch.c: if (fread (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: if (fseek (asm_out_file, 0, SEEK_END) != 0)
> c-family/c-pch.c: || fwrite (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: asm_out_file. */
>
> I do not understand this at all. In what way does PCH have anything to
> do with writing out to asm_out_file?!
>
>
> asm_out_file for NEXT runtime ABI v01:
> objc/objc-next-runtime-abi-01.c:#include "output.h" /* for asm_out_file */
> objc/objc-next-runtime-abi-01.c: ASM_DECLARE_UNRESOLVED_REFERENCE
> (asm_out_file, string);
> objc/objc-next-runtime-abi-01.c: ASM_DECLARE_CLASS_REFERENCE
> (asm_out_file, buf);
>
> This seems to imply that LTO doesn't work with LTO. The functions that
> use asm_out_file are handle_next_class_ref and handle_next_impent,
> which both only output something for darwin, and are only called via
> called from objc_generate_v1_next_metadata for ABI v1. This code is
> probably not tested very well, because this is for the 32-bits
> ObjC-v2.0 ABI on Darwin, whereas the default 32-bits ABI is ObjC-v1.0
> The code that invokes these functions is this:
>
> /* Dump the class references. This forces the appropriate classes
> to be linked into the executable image, preserving unix archive
> semantics. This can be removed when we move to a more dynamically
> linked environment. */
>
> for (chain = cls_ref_chain; chain; chain = TREE_CHAIN (chain))
> {
> handle_next_class_ref (chain);
> if (TREE_PURPOSE (chain))
> generate_classref_translation_entry (chain);
> }
>
> for (impent = imp_list; impent; impent = impent->next)
> handle_next_impent (impent);
>
> What is this "more dynamically linked environment" mentioned here? Is
> this an ABI that GCC needs to continue to support?
>
> (BTW, the GCC manual says: "Starting with GCC 4.7.0, the traditional
> GNU runtime API is no longer available." Shouldn't that be mentioned
> as a caveat in gcc-4.7/changes.html?)
>
>
> Hopefully I can eliminate the remaining #include output.h cases from
> the front ends before the end of Stage 1. Once that's done, I'll
> propose to add GCC_OUTPUT_H to the poisoned identifiers list under
> system.h:IN_GCC_FRONTEND.
>
> Thanks for any help you can offer,
>
> Ciao!
> Steven
