------- Additional Comments From hjl dot tools at gmail dot com 2008-03-10 03:43 ------- (In reply to comment #4) > I think you need to qualify what you say. It is clearly true that the > st_shndx > field of a symbol is not a pure section index. Any value above LORESERVE is > indeed reserved. The ELF ABI defines what to do for a symbol whose section > index is larger than LORESERVE: put SHN_XINDEX in the st_shndx field, and put > the real section index in the corresponding entry in the SHT_SYMTAB_SHNDX > section. Note that the ABI does not say to store the section index plus 256; > it > says to store the section index. > > None of this has anything to do with the sh_link field in section header 0 > when > the section string table is larger than LORESERVE. In that case, I think the > ELF ABI says to put the section index in the sh_link field. It does not say > to > put the section index plus 256. Currently BFD is putting the section index > plus > 256. I think that is wrong.
I think it is up for debate. I can see the point for the current BFD behavior. That is each section index is unique, including special ones. When I say section index 0xfff2, there is no ambiguity about which section it refers to. Would you mind raising your concern at http://groups.google.com/group/generic-abi > For the original test case, for a symbol defined in a section whose index is > larger than LORESERVE, what does icc put in the SHT_SYMTAB_SHNDX section? > Does > it put the section index, or the section index plus 256? I believe that the > ELF > ABI says that it should store the former. BFD stores the latter. What does > the > BFD readelf -s report for those symbols in the object compiled by icc? Would you mind downloading icc to check it out? I believe icc is free for non-commercial use. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
