This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[LTO, RFA] Re: [PATCH] Fix PR42531: lto generates invalid assembler ".section" directives.


[ Redirecting to the main list.  Are any of the LTO maintainers able to
comment on this? ]

  Background: We have a problem on non-ELF platforms, because LTO generates
section names with asterisks in them (based on the DECL_ASSEMBLER_NAME of
various decls), which may be OK for section names within ELF format
containers, but isn't allowed on (at least some) non-ELF platform(s) for the
name of the section (in the native object format) containing the ELF data.

H.J. Lu wrote:
> On Wed, Dec 30, 2009 at 9:02 AM, Dave Korn

>> gcc/ChangeLog:
>>
>>        * lto-streamer-out.c (produce_asm): Skip any leading asterisk when
>>        using DECL_ASSEMBLER_NAME to generate a section name.
>>        (copy_function): Likewise.
>>
>>
>>  Bootstrapped and tested on i686-pc-cygwin; no new FAILs and resolves four
>> FAILs arising from gcc.c-torture/compile/20011119-1.c.  Ok?
>>
> 
> The fix is wrong/incomplete. See my comments in
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531

  Ah, I think "incomplete" is the most likely option.  Sorry for not noticing
this; the test FAILs on all non-ELF platforms either way, because it requires
symbol visibility support, which doesn't exist elsewhere.

  Looking at the code the issue with asterisks seems to have been handled in
an ad-hoc fashion, so there is perhaps yet another place generating section
names, this time as reference rather than definition, that needs to skip
asterisks.

  Rather than continue tracking them down one by one, I will try modifying
lto_get_section_name() itself to skip a leading asterisk, which might have
been the better approach to try in the first place.  I'll bootstrap it on a
linux system and see if it solves these new FAILs.

  I don't mind reverting the patch I applied, if anyone wants; if the new
approach works it would obviate the need for it.  However it shouldn't be
harmful once the new patch is applied, which shouldn't take too long to
determine, so I won't revert it immediately unless anyone specifically asks.

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]