[Bug binutils/15835] binutils can't deal with more than one SHT_SYMTAB_SHNDX section (such as from Solaris or illumos link editor)
https://sourceware.org/bugzilla/show_bug.cgi?id=15835 Ali Bahrami changed: What|Removed |Added CC||ali_swbugzilla at emvision dot com --- Comment #3 from Ali Bahrami --- As additional evidence that binutils/bfd are wrong in preventing more than one SHT_SYMTAB_SHNDX, I'd like to reference this discussion in the ELF gABI list where we just modified the ELF spec to make it clear that multiple such sections are allowed: https://groups.google.com/forum/#!topic/generic-abi/-XJAV5d8PRg So binutils should be fixed. However, I think it's also probably true that the Illumos ld, as with the Solaris ld, needs to be updated to understand the special section merging rules that the GNU linkers use to remerge the sections that result from the use of -ffunction-sections. Extended sections really shouldn't occur in an executable or shared library. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 Ali Bahrami changed: What|Removed |Added CC||ali_swbugzilla at emvision dot com --- Comment #4 from Ali Bahrami --- I don't know the bfd code, so please forgive a probably off base comment... This fix seems to be giving the section a pass based on its section type being in the OS-specific range. That would work, but is there a reason to not simply translate any non-zero sh_link? The Solaris strip always translates sh_link. It only translates sh_info in a handful of cases that it specifically knows are section indexes, and otherwise leaves it unaltered. So far, this seems to have been OK (no complaints that I know about), and is a bit more general. In any event, thanks for this fix. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 --- Comment #7 from Ali Bahrami --- I understand your concerns. Our assumption is that sh_link is always 0, or a section index, while the meaning of sh_info is somewhat more variable, and may or may not be. This is ancient "From New Jersey" code, which is somewhat short of a proof of correctness. In any event special case handling of sh_info is clearly necessary. With that in mind, this proposed fix is a step in the right direction, but it's not enough, because we really need the section indexes to be translated correctly for our OSABI sections. In the examples provided by Rainer for instance, the sh_link for both of those sections is definitely a section index, and so in a situation where sections are added or removed, preserving them without translating them is going to be wrong, and perhaps even worse that just zeroing. Can I ask you to add the necessary os-specific translations? The list is pretty short, and can be found here in Table 13-9 (ELF sh_link and sh_info interpretation): https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#scrolltoc You will already have the gABI cases covered, so you only need updates for the SHT_SUNW_ cases. The numeric values for these types are as follows: #define SHT_SUNW_ancillary 0x6fee #define SHT_SUNW_cap0x6ff5 #define SHT_SUNW_capinfo0x6ff0 #define SHT_SUNW_symsort0x6ff1 #define SHT_SUNW_tlssort0x6ff2 #define SHT_SUNW_LDYNSYM0x6ff3 #define SHT_SUNW_move 0x6ffa #define SHT_SUNW_COMDAT 0x6ffb #define SHT_SUNW_syminfo0x6ffc #define SHT_SUNW_verdef 0x6ffd #define SHT_GNU_verdef SHT_SUNW_verdef #define SHT_SUNW_verneed0x6ffe #define SHT_GNU_verneed SHT_SUNW_verneed #define SHT_SUNW_versym 0x6fff #define SHT_GNU_versym SHT_SUNW_versym It would be correct to preserve and not alter the values for any other section types in the OS-specific range. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 --- Comment #8 from Ali Bahrami --- My understand of sh_link and sh_info is the same as what Cary outlined above, with one comment. We've seen cases were sh_info should have been treated as a section index, where SHF_INFO_LINK was not set. This is wrong, but we still do have some code that "knows" what sh_info contains without regard for SHF_INFO_LINK, just to work around that. I'd be content for objcopy/strip to follow the rule Cary outlined though --- if we're not setting SHF_INFO_LINK properly, that's a bug we can deal with ourselves (and I think we're OK in that regard). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 --- Comment #12 from Ali Bahrami --- I've sent an email with a more detailed reply. I think that propagating SHF_STRINGS, if set, should be done for all platforms, and not just for Solaris. We do seem to be unique in setting it today, but note that its a generic ELF flag, and it would be legal on any platform. Given support for the rules Cary gave earlier, I don't believe that Solaris needs the special back end handling that this patch adds. I don't know if it would be useful on other platforms, or whether its nice to have as a bit of insurance for future issues. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 --- Comment #23 from Ali Bahrami --- > Ali, Rainer. Thomas - please could you try out this version and let me know if > you are happy with it. > > One thing that this patch does not do is zero the p_paddr fields of the > program > headers for Solaris targets. I did look at doing this, but it would a lot of > hacking on very complicated, fragile code in the BFGD library. Something that > I think would be very likely to introduce new bugs. Hi Nick, Rainer and I just compared notes, and we're happy with it. These little breakages have been a chronic pain in the neck for us, and it's going to be really helpful for us once we pull in this patch. Thanks for all the work you put in to help us with this. For the record, I don't believe that Solaris ever sets p_paddr, or looks at it, so the fix for this could probably be as simple as "if (solaris) phdr->p_paddr = 0". On the other hand, it's purely cosmetic. The values you're writing there seem to correspond to something sensible (same as p_vaddr), and there's really no reason to put any extra work into it. Leave it alone. Thanks again... - Ali -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Ali Bahrami changed: What|Removed |Added CC||ali_swbugzilla at emvision dot com --- Comment #7 from Ali Bahrami --- We think it's not a linker bug. The 32 and 64-bit sparc platform ABIs are distinct, and here, we're talking about relocations defined for 64-bit objects, but not for 32-bit ones. The error from ld seems legit, and is intended to catch this case. The 2 tables of sparc relocations (32 and 64-bit) can be found here: https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-62988 This question wouldn't come up if we were discussing x86, where the 32 and 64-bit relocations are pretty different, but with sparc, where the 64-bit case is essentially an extension of the 32-bit case, that's probably less obvious. Just to be sure, I checked with our resident sparc architecture expert, and he told us: I'm not exactly sure what the question is. The relocations are for late binding of the value of a symbol. Symbol values in a 32-bit program cannot be larger than 32-bits, AFAIK. Now relocations are a little more complicated, because they encode an expression. So, we could have relocations that encode an expression that is larger than 32-bits for a 32-bit program. But there has been no need for them, so they were never created, AFAIK. It would certainly be possible to create some 64-bit relocation expressions for 32-bit programs. I would want to see some better justification before creating them, though. And some assembler syntax might be necessary to disambiguate which relocation should be used in some circumstances. Which I will simplify to "we haven't needed that relocation for 32-bit sparc, so it doesn't exist". Another engineer here mentioned the following: For what it's worth, Go's internal linker handles this by generating two relocations internally -- one for the lower half of the 64-bit value and one for the upper half of the 64-bit value. This tends to work out nicely since you have to load each half separately anyway: // R_ADDRSPARC64LO (only used on sparc64) resolves to low 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64LO // R_ADDRSPARC64HI (only used on sparc64) resolves to high 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64HI That squares with Nick's earlier comment Does it, for example, produce two 32-bit relocs, one for the lower 32-bits and one for the upper 32-bits ? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
