Re: libstdc++: xfail 27_io/ios_base/storage/11584.cc on

[Zack Weinberg <zack at codesourcery dot com>]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

> No.  I was talking about the 32-bit SOM linker.  However, a lot
> of stuff in HP's elf linker was derived from their SOM linker.
> Their notion of weak symbols was clearly derived from the secondary_def
> support in the SOM linker.  As far a I can tell, the SOM linker
> doesn't support comdat groups.  However, I have found that one
> can create multiple subspaces (sections) with the same section name
> (e.g., $CODE$ or $DATA$) with different comdat keys and the linker
> will pick one instance of each subspace from a set of files.

Oh!  That's what aCC is doing in 32-bit mode!  I saw it emit object
files like this but I couldn't figure out what they meant.  (It
doesn't help that objdump can't see those comdat keys.  odump labels
both those sections and the symbols they contain 'K' but I don't know
what that means.)

> It's possible that something similar could be done with the 64-bit
> elf linker and with the 32-bit port under hpux 11.  I'm just not sure
> how comdat and secondary_def (weak) symbols will interact.  If it works,
> it should reduce binary file sizes.

Well, in 64-bit mode, aCC emits sections with those SHF/SHN_HP_COMDAT
flags I was talking about, all named ".text", but the symbols inside
are not weak.  But then, if you have comdat groups, do you need to
make the symbols weak?

zw