| Summary: | ld -r silently renames sections | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Jan Beulich <jbeulich> |
| Component: | ld | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug-binutils |
| Priority: | P2 | ||
| Version: | 2.15 | ||
| Target Milestone: | --- | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Last reconfirmed: | |
Ian's comment isn't exactly right. Current ld behaviour is as he says it should be, that is, two orphan sections with the same name and compatible flags will be linked to the same output section. Since I also think current ld behaviour is correct, I'm closing this bug report. Note the difference between the original description and your response: The original text is talking about a difference in allocation flags (one section has the SHF_ALLOC flag set, the other [identically named in another object file] doesn't), while you're talking about compatible flags (which these aren't). The thing is that current behavior results in entirely different behavior when, using in both cases the same linker script mentioning the questionable section, (a) linking the original object files into an executable and (b) combining the original object files into intermediate object files and only then linking those into an executable. I continue to believe that in these two scenarios the outcome should be the same, requiring that the linker does not rename one of the two input sections when using -r. I understand your original description, and still think current ld behaviour is correct. Many people seem to think that "ld -r" can be used much like "ar" to package a group of objects together, and that the resultant object will link into a final executable to produce the same result as if the original objects were directly linked. This is *not* true in general. I can't judge whether or under what conditions this might not be true, but I can't immediately see why it wouldn't be. Independent of that, (silently) renaming a section seems unacceptable to me. The more that in ELF one doesn't even have to, since sections are not solely identified by their name, but instead the pair (name, flags) serves as the full identification. Thus I believe that not only the renaming is a problem in ld, but also the combining of what you call compatible sections (instead, if names match but flags are different, two output sections should be generated). http://sources.redhat.com/ml/binutils/2004-10/msg00178.html It might be reasonable to change ld -r so that an attempt to combine two input sections with incompatible flags results in two output sections of the same name. Fixed in 2.20 |
Encountering two input sections with different allocation flags but identical names, ld renames the second one encountered by attaching a .<number> suffix. While the ELF spec isn't really explicit about this, it would have been my understanding that an ELF section is uniquely identified by {name,type,flags} rather than just by its name. At the very least I'd expect ld to be able to optionally issue a warning to the user that this happened (especially when -r is in effect), because (for instance) linker scripts subsequently used to deal with the resulting output may deal only with the un-renamed sections unless the programmer(s) learn(s) that it needs to deal with more. The problematic code is ld/emultempl/elf32.em, function gld${EMULATION_NAME}_place_orphan calling bfd_get_unique_section_name. And a response to this I got on the mailing list from Ian Lance Taylor: Oh yeah. I think this code may be buggy. It was intended to handle the case in which an input section was orphaned even though the output section exists. That can happen if, for example, the output section is created by the linker for whatever reason. However, the way the code is written, if two orphaned input sections have the same name, the second one will get a unique output section name. Really they should both go into the same output section (if the flags are compatible). That is, the test should not be unconditional on whether an output section exists with the same name. Perhaps we should test SEC_LINKER_CREATED, if that is used consistently. You are correct that in the case of incompatible flags, or SEC_LINKER_CREATED, the linker should arguably create a new section with the same name and the appropriate flags. This is where we may run into trouble with the way that linker scripts base everything purely on the section name. On the other hand, it may work fine, as place_orphan sets up the appropriate links directly.