Chris is right. I believed that two .debug_str sections with different flags would not be merged. Ali, you say different: you say these sections with different flags should be merged. In the script output from a machine with a fixed linker, we can see that they *are* being merged.
Here at IBM Rational, we are not using OpenSolaris at all - we are tasked with making things work on Solaris 10, not OpenSolaris. What external version of Solaris 10 will have this linker fix, and in what expected timeframe? Also, could you please pass judgment on this workaround: when Purify sees a .debug_str section, we zero out the flags. This way the linker always see identical flags - zero. Do you think that will cause any problems? It would result in programs linked with Purify being *more* debuggable than the program built without Purify. But is it harmful in any way? -- Allan Pratt, apratt at us.ibm.com Rational software division of IBM Chris Quenelle <Chris.Quenelle at Sun.COM> Sent by: Chris.Quenelle at Sun.COM 10/30/2006 03:58 PM To Ali Bahrami <Ali.Bahrami at Sun.COM> cc tools-linking at opensolaris.org, Allan K Pratt/Cupertino/IBM at IBMUS, Eric.Sosman at Sun.COM, Seizo Sakurai <Seizo.Sakurai at Sun.COM> Subject Re: [tools-linking] ld bug related to section merging with different flags The script was written with the assumption that the flags must be equal in order to concatenate the two sections together. It detects different flags, and then warns about a problem. The problem is not that the flags are different the problem is that the linker should be combining the two sections (without merging them) even though the flags are different. --chris Ali Bahrami wrote: > Following up on my own response, I just ran the script from the original > message > on my development machine (sorry, I should have done that before): > > % sh foo /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/amd64/libgcc.a > Your copy of /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/amd64/libgcc.a > does have the problem being demonstrated by this test. > The .debug_str section in at least one member, _absvdi2.o, > has nonzero flags, so it will not merge with object files > you compile with gcc, which have no bits set in sh_flags. > > See the dumps below for proof. > > ========================================================================= > > Partial elfdump of libgcc.a member _absvdi2.o showing .debug_str > section flags. > Notice in this dump that there is a .debug_str section with nonzero > sh_flags: > > Section Header[18]: sh_name: .debug_str > sh_addr: 0 sh_flags: [ SHF_MERGE > SHF_STRINGS ] > > ========================================================================= > > Partial elfdump of object file test.o, showing .debug_str section > flags. > Notice in this dump that there is a .debug_str section with sh_flags > = 0: > > Section Header[19]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > > > ========================================================================= > > Partial elfdump of linked a.out , showing debug_str sections and flags. > Notice that there are two debug_str sections, in violation of DWARF > rules. > > Section Header[35]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > > There's only 1 .debug_str section... > > - Ali
