This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Support mixing COMDAT and linkonce


On Wed, May 19, 2004 at 12:06:22PM +0930, Alan Modra wrote:
> 
> Whoa!  HJ, you haven't even answered the basic question of whether the
> linker should be doing anything special when confronted with a mix of
> COMDAT (new style link-once) and .gnu.linkonce.* (old style link-once)
> sections.  It's not clear to me that we should even try to handle this
> situation, and what should be done with real groups containing multiple
> sections when just one of the sections matches an old style link-once
> section.
> 
> Secondly, you haven't justified your design.  I think that comparing
> symbols exported from a section in order to determine whether a
> section is a duplicate is a clever idea, but it doesn't exactly fit
> in with the current linker handling of link-once sections.  We currently
> just look at section flags and names, discarding sections that have
> the SEC_LINK_ONCE flag set and the same name as another SEC_LINK_ONCE
> section.  There are some more flags that determine whether the linker
> should warn always on discarding, or warn when the section size doesn't
> match, or warn when section contents don't match (currently
> unimplemented).  Your checking of symbols really fits in with these
> warning options.  (And it might be a neat way to implement
> SEC_LINK_DUPLICATES_SAME_CONTENTS in the face of needing to support
> link-once sections compiled with different gcc optimizations.)
> 
> So please spend some time describing why this solution of yours is
> necessary, and also why this solution is the best one.  After these
> design issues have been discussed, then perhaps we can move on to
> looking at implementation details.


Sometimes compiler has to use the same symbol in both linkonce and
comdat implementation where one linkonce section is replaced by a
section group containing a single section. One case is people put
a variable in a linkonce data section. I agree we can't cover cases
where a section group with multiple sections replaces multiple
linkonce sections.

My goal is to allow mixing comdat section groups containing a single
section with linkonce sections, compiled with different optimizations.
Comparing section name works for linkonce sections. But section name
is not very useful for comdat groups. Is this requirement reasonable?


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]