sh-elf toolchain broken on mainline

sh-elf toolchain broken on mainline

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Every single execution test fails to compile with the error message:

/swbuild/nightly/2003-04-28/sh-elf/gcc/collect-ld: /swbuild/nightly/2003-04-28/s
h-elf/gcc/testsuite/20000112-1.x0: hidden symbol `__dso_handle' isn't defined

The symbol __dso_handle should both used and defined in crtbegin.o, made
gcc/crtstuff.c .  Since sh-elf uses "_" as USER_LABEL_PREFIX, the actual
symbol in the symbol table should be ___dso_handle .
If nm and/or strings are to be trusted, that is not the case:

00000000 D ___dso_handle
         U __dso_handle

I.e. the definition gets the USER_LABEL_PREFIX, but the use does not -
I haven't found out why yet.

ld used to silently ignore this problem, and since sh-elf is a newlib
based target which generally doesn't use dsos, this was by and large
a non-issue.  Most gcc tests still passed on Friday.
Now, with ld giving a hard error, this problem means that you can't link
any gcc-compiled program.

I've attached the crtbegin.o that was generated from today's sources.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

[-- Attachment #2: crtbegin.o --]
[-- Type: application/octet-stream, Size: 1920 bytes --]

RFA: fix default_assemble_visibility (Was: sh-elf toolchain broken on mainline)

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Joern Rennecke wrote:
	
> The symbol __dso_handle should both used and defined in crtbegin.o, made
> gcc/crtstuff.c .  Since sh-elf uses "_" as USER_LABEL_PREFIX, the actual
> symbol in the symbol table should be ___dso_handle .
> If nm and/or strings are to be trusted, that is not the case:
> 
> 00000000 D ___dso_handle
>          U __dso_handle
> 
> I.e. the definition gets the USER_LABEL_PREFIX, but the use does not -
> I haven't found out why yet.

It turns out that gcc emits the symbol for the .hidden directive incorrectly -
instead of using assemble_name, it strips the name encoding manually, and
then calls fprintf with the result.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

[-- Attachment #2: hidden-fix --]
[-- Type: text/plain, Size: 1204 bytes --]

2003-04-28  J"orn Rennecke <joern.rennecke@superh.com>

	* varasm.c (default_assemble_visibility): Use assemble_name.

Index: varasm.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.345
diff -p -r1.345 varasm.c
*** varasm.c	28 Apr 2003 04:13:48 -0000	1.345
--- varasm.c	28 Apr 2003 18:56:13 -0000
*************** default_assemble_visibility (decl, vis)
*** 4485,4496 ****
  
    const char *name, *type;
  
!   name = (* targetm.strip_name_encoding)
! 	 (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
    type = visibility_types[vis];
  
  #ifdef HAVE_GAS_HIDDEN
!   fprintf (asm_out_file, "\t.%s\t%s\n", type, name);
  #else
    warning ("visibility attribute not supported in this configuration; ignored");
  #endif
--- 4485,4497 ----
  
    const char *name, *type;
  
!   name = (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
    type = visibility_types[vis];
  
  #ifdef HAVE_GAS_HIDDEN
!   fprintf (asm_out_file, "\t.%s\t", type);
!   assemble_name (asm_out_file, name);
!   fprintf (asm_out_file, "\n");
  #else
    warning ("visibility attribute not supported in this configuration; ignored");
  #endif

gcc 3.3 default_assemble_visibility problem (Was: Re: sh-elf toolchain broken on mainline)

[Joern Rennecke]

P.S.:

This problem is likely to affect other targets besides sh-elf.
On any target where USER_LABEL_PREFIX is not empty, or
ASM_OUTPUT_LABELREF does any other non-identity operations,
and which does not define its own way to output hidden symbols,
hidden symbol output will be incorrect, not making the intended
symbol hidden, and creating an undefined hidden symbol with a
different name instead - likewise for internal and protected
symbols.

The following port config files define USER_LABEL_PREFIX to "_":
arm/aout.h
arm/coff.h
arm/pe.h
c4x/c4x.h
cris/cris.h
dsp16xx/dsp16xx.h
h8300/elf.h
h8300/h8300.h
i386/bsd.h
i960/i960.h
ip2k/ip2k.h
m68k/m68k.h
m88k/m88k.h
pdp11/pdp11.h
romp/romp.h
sh/coff.h
sh/embed-elf.h
sparc/sparc.h
v850/v850.h
vax/vax.h

Moreover, ASM_OUTPUT_LABELREF is defined by the
following further config files:
alpha/alpha.h
arc/arc.h
arm/aof.h
arm/arm.h
arm/pe.h
i370/i370.h
i386/cygming.h
ia64/sysv4.h
mcore/mcore.h
mips/mips.h
mmix/mmix.h
mn10200/mn10200.h
mn10300/mn10300.h
pa/pa.h
rs6000/linux64.h

OTOH, Only rs6000/rs6000.c defines TARGET_ASM_ASSEMBLE_VISIBILITY
With the release of binutils 2.15 - or maybe already 1.14.1 -
the damage will become apparent for all of the above targets that
use binutils - i.e. most of the ones that are not already dead.

Unless my patch:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg02110.html
or an equivalent is accepted for the 3.3 branch, we should make
target-specific patches to all targets that we don't want to deprecate.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: gcc 3.3 default_assemble_visibility problem (Was: Re: sh-elf toolchain broken on mainline)

[Andreas Schwab]

Joern Rennecke <joern.rennecke@superh.com> writes:

|> The following port config files define USER_LABEL_PREFIX to "_":

|> m68k/m68k.h

Only non-ELF, which don't support visibility anyway.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFA: fix default_assemble_visibility (Was: sh-elf toolchain broken on mainline)

[Mark Mitchell]

On Mon, 2003-04-28 at 11:57, Joern Rennecke wrote:
> Joern Rennecke wrote:
> 	
> > The symbol __dso_handle should both used and defined in crtbegin.o, made
> > gcc/crtstuff.c .  Since sh-elf uses "_" as USER_LABEL_PREFIX, the actual
> > symbol in the symbol table should be ___dso_handle .
> > If nm and/or strings are to be trusted, that is not the case:
> > 

Your patch is OK; please check it on the mainline and on the branch.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com