I don't know if this is related or not but on snv_23 (x86 pentium4) a simple C `hello world' program binary causes dbx to hang. Using mdb is fine. Using dbx on s10 GA also works. I don't know if this happens in any of the previous Nevada builds as I mainly use mdb but was trying to show someone how to use the 'stop modify' dbx command.
--Marc On 9/30/05, Chris Quenelle <Chris.Quenelle at sun.com> wrote: > > > 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 > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/tools-linking/attachments/20051002/723443c8/attachment.html>
