[Bug libc/467] New: Build fails on sparc when gcc supports comdat

[Bug libc/467] New: Build fails on sparc when gcc supports comdat

[mmazur at kernel dot pl]

Repasting my mail from libc-alpha: 
 
This is what glibc does on sparc: 
 
#   define __make_section_unallocated(section_string)   \ 
        asm (".section " section_string "\n\t.previous"); 
 
__make_section_unallocated 
  (".gnu.linkonce.b.__sparc32_atomic_locks, \"aw\", %nobits"); 
 
volatile unsigned char __sparc32_atomic_locks[64] 
  __attribute__ ((nocommon, 
        section (".gnu.linkonce.b.__sparc32_atomic_locks" "\n\t#"), 
                  visibility ("hidden"))); 
 
On gcc without comdat this results with two .section entries: 
 
    .section .gnu.linkonce.b.__sparc32_atomic_locks, "aw", %nobits 
 
    .section    .gnu.linkonce.b.__sparc32_atomic_locks 
    #,"aw",@nobits 
 
As one can see, that's a smart move to define '%nobits' instead of  
'@nobits' (whatever that does :). 
 
On gccs with comdat support the same code results in: 
 
        .section .gnu.linkonce.b.__sparc32_atomic_locks, "aw", %nobits 
 
        .section        .bss,"awG",@nobits,.__sparc32_atomic_locks 
        #,comdat 
 
This results in (a) additional definition  
of .gnu.linkonce.b.__sparc32_atomic_locks section (which is empty and kind of  
useless) and (b) commenting out comdat definition which causes conflicts when  
linking (since that definition is supposed to replace .gnu.linkonce). 
 
A fix to just make it compile is simple - removal of "\n\t#". But what about  
that nobits hack? It's there for a reason (right? :) and it can't be  
'rehacked' in the same way since .section syntax changed.

-- 
           Summary: Build fails on sparc when gcc supports comdat
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: mmazur at kernel dot pl
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[mmazur at kernel dot pl]

------- Additional Comments From mmazur at kernel dot pl  2004-10-30 22:00 -------
Created an attachment (id=245)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=245&action=view)
Short patch that just makes it build (no comdat detection)


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[aj at suse dot de]

------- Additional Comments From aj at suse dot de  2004-12-19 14:27 -------
Jakub, could you look at this?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gotom at debian dot or dot  |jakub at redhat dot com
                   |jp                          |
             Status|NEW                         |ASSIGNED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-12-20 12:40 -------
Well, both GCC 3.3.4 and 3.4.0 for
volatile unsigned char __sparc32_atomic_locks[64]
__attribute__ ((nocommon, section (".gnu.linkonce.b.__sparc32_atomic_locks"),
                visibility ("hidden")));
generate
.section        ".gnu.linkonce.b.__sparc32_atomic_locks",#alloc,#write
and not what you wrote, so what the code does ATM is really needed, otherwise
the whole .bss section becomes SHT_PROGBITS.

Even current gcc-3_4-branch sparc.c has /* ??? Handle SECTION_BSS.  */
in sparc_elf_asm_named_section and so does GCC HEAD (and I don't see how
CVS GCC even does anything about comdat groups on SPARC at all).
So my guess is you are using some local hack.

So you clearly are us

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-12-20 12:42 -------
Oops, sorry for the last half sentence that slipped in.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-12-20 12:51 -------
Actually, I should follow up.  IMHO the right thing is in GCC to:
-  if (flags & SECTION_MERGE)
+  if ((flags & SECTION_MERGE)
+      || (HAVE_GAS_COMDAT_GROUP && (flags & SECTION_LINKONCE)))
in GCC HEAD's sparc_elf_asm_named_section and then glibc can cope with this,
but it first needs to know what GCC 4+ behaviour will be in this case.

So, if you want to resolve this, please test and submit a GCC HEAD patch along
those lines.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[mmazur at kernel dot pl]

------- Additional Comments From mmazur at kernel dot pl  2004-12-20 15:00 -------
(In reply to comment #3) 
> So my guess is you are using some local hack. 
 
I wouldn't call it a hack - it's H.J. Lu's patch for using comdat if gas supports it (patch from 
2004-07-09). Here's an excerpt from our gcc's changelog: 
 
Revision 1.217.2.71  2004/08/07 00:49:17  qboosh 
- added pr16276 patch (fixes libstdc++ linking on ia64; 
  needs binutils with COMDAT support) 
 
With new binutils the comdat handling changed (got more restrictive?) and I've had to patch 
i686 too (http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/glibc-comdat.patch). 
 
Though we've lost our ia64 builder since then, so I'll probably drop that gcc patch altogether 
- it's starting to be a real pain in the neck. 
 

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/467] Build fails on sparc when gcc supports comdat

[pasky at suse dot cz]

------- Additional Comments From pasky at suse dot cz  2010-06-01 01:59 -------
this obviously seems to be n/a by now

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=467

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.