This issue came up in April, and I don't think I got an answer to my question back then. The following alignment issue only causes problems on Sparc.
I was investigating 6244747 at the time. In that bug, the kernel hangs when it should be causing a SIGBUS. The fix causes the kernel not to hang. That bug doesn't directly relate to the this alignment issue. The *sections* in an ELF file each have a specified alignment. QUESTION: What is the alignment of the ELF section header table itself? Is this specified in the manual or the relevant standards or anything? There is a recent change in the link editor that has caused the section headers of ELF64 libraries to show up with only 32-bit alignment. Unfortunately I don't have a test case that shows this behavior, I just see libraries showing up in Solaris that have the new alignment. (Notice I haven't used the word "misaligned" because I don't know what the alignment is supposed to be.) In dbx we mmap an ELF file, and then cast the section header memory into a pointer to an Elf64_Shdr and start pulling 64-bit data out of it. The compiler assumes that any memory of this type will be 64-bit aligned, so it generates 64-bit loads. The result is dbx is crashing on S10u1 machines because several of those libraries now have 32-bit aligned section headers. One of those libraries is libCrun.so which affects every C++ program. It really seems like the section header should 64-bit aligned (relative to the start of the file) in a 64-bit library. If necessary, we can patch this problem in all released dbx binaries so that they work on Solaris 10u1. But it could have a noticable impact on S10u1 adoption among our customers. Out of curiosity does 64-bit libld.so assume that the 64-bit .o files that it processes will have 64-bit aligned section headers? If it just mmaps the input files, and casts an address to a structure pointer, it might suffer from the same problem that dbx now has, if the compiler or assembler was to loosen the alignment restrictions to 32-bits when generating an object file. --chris
