Marc, I don't think x86 has any way for misaligned loads to cause traps. It just deals with any misalignment in hardware. (Other than an SSE2 load "movdqa" which is only for 128 bit data).
Perhaps you are running into this bug instead: http://monaco.sfbay/detail.jsf?cr=6328251 Nobody in the dbx group has had a chance to look at this one yet. --chris Marc Rocas wrote: > 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 > <mailto: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 <mailto:tools-linking at opensolaris.org> > >
