On Tue, Aug 05, 2008 at 04:14:07PM +0200, Petter Reinholdtsen wrote: > [Wouter Verhelst] > > it's usually safe to trust the compiler to know what will be > > fastest. > > I agree. > > > Why have them in the first place? If you just remove them all, that > > will surely fix the issue. > > To me it is more a question of how to be sure all of them are removed > in a way that get insserv working. For that, I would like someone > with m68k access to come up with a patch, thus making sure the patch > actually solve the problem on m68k. Because of this, I hope you or > someone else with m68k machines can provide a tested patch.
'grep -r attribute *' in the source directory only comes up with four lines. One of them is a macro that makes things align on sizeof(something*), which isn't likely to be a problem in the real world (I've yet to see an architecture where alignment on the size of a pointer is going to be problematic), and two of the others align on sizeof(char*). The last two are the problematic ones in this bugreport... But, sure, I can test-build on an m68k machine. I'll let you know what the results are. > >> What is the value of sizeof(regex_t) on m68k? What is the alignment > >> calculated for the struct? > > > > sizeof(regex_t) is 30 on m68k, so I guess that's also what the > > calculated alignment is. > > Now I am confused. The error complained that the alignment wasn't on > 2-byte boundaries, if I understood it correctly. Actually, it complained about it not being aligned on a power-of-two boundary. 30 isn't a power of two. Your confusion is a result of my confusion in this bugreport, where I confused the fact that m68k, occasionally, also requires alignment on a 2-byte boundary on the frame pointer -- but that is so entirely and utterly different from what we're talking about here that it isn't even funny. Sorry about that. In reality, m68k requires access aligned to the length of a data type; i.e., 1-byte for char, 2-byte for short, and 4-byte for int/float/pointer (though it gets less clear after that). In order to be able to enforce this requirement, the ABI introduces a requirement that structs be aligned to the size of their largest member, and gcc turns that into a power-by-two alignment requirement (if I read the ABI docs correctly). In any case, aligning on 30 bytes will surely break the 4-byte requirement of pointers and ints, which regex_t does contain. > 30 is divisable by 2, and thus aligning on 30 byte boundaries should > also be on 2-byte boundaries. Indeed. But that's not the problem. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
