This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++: xfail 27_io/ios_base/storage/11584.cc on
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 26 Apr 2004 20:01:00 -0700
- Subject: Re: libstdc++: xfail 27_io/ios_base/storage/11584.cc on
- References: <200404270238.i3R2cc2S003189@hiauly1.hia.nrc.ca>
"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