tags:

views:

651

answers:

5

Is it somehow possible to catch data-alignment faults even on i386? Maybe by setting a i386 specific machine register or something like that.

On Solaris-Sparc I am receiving a SIGBUS in this case, but on i386 everything is fine.

Environment:

  • 32-bit application
  • Ubuntu Karmic
  • gcc/g++ v4.4.1

EDIT: Here is why I am asking this:

  • our application crashes on Sol-Sparc with SIGBUS. For the purpose of debugging I would try to get a similar behavior on our i386 platform.
  • our Sol-sparc machine is very slow, so compiling and debugging takes a lot of time there. And our i386 machine is unbelievable fast (8 cores, 32G memory).
  • Even on i386 platforms there is a cost of performance on data-alignment faults. And therefore I would like to fix data-alignment faults wherever possible.
A: 

Intel built in unaligned transfers from the start - it was one of the selling points when x86 was brand new. I understand your reasons for wanting to trap unaligned access, but I don't think it's possible.

Edit: very glad to be proven wrong.

Mark Ransom
you where not completely wrong. Although SIGBUS can be forced even on i386 it doesn't help that much. That's because on the SPARC a "stack mis-alignment" is not considered harmful and does not cause a SIGBUS. But on i386 it causes SIBGUS even for a harmless "stack mis-alignment" when the AC flag is set.
+6  A: 

Meanwhile I found an Intel CPU document addressing this topic.

See Intel® 64 and IA-32 Architectures Software Developer’s Manual.

It seems to be difficult to put all this stuff together. However it doesn't sound like it is completely impossible. The interesting chapter is 4.10.5 Checking Alignment

EDIT (some condensed material from the mentioned document):

page 5-60

Interrupt 17 Alignment Check Exception (#AC)

to enable alignment checking, the following conditions must be true:

AM flag is set(bit 18 of control regisster CR0)
AC flag is set (bit 18 of the EFLAGS)
The CPL is 3 (protected mode or virtual-8086 mode).

additionally - in 14.8.2.6 - Memory Controller Errors are mentioned. I don't know if it is the same only in other words:

table 14-11, Encoding of MMM and CCCC Sub-Fields
Address/Command Error  AC  011
Unfortunately, user-mode code all runs in ring 3; the above won't generate exceptions.
ephemient
I lack knowledge about these CPU "rings". But if a normal program uses ring-3 then it would be good enough.
Sorry, I misread earlier; "The processor does not generate alignment exceptions when operating at privilege level 0, 1, or 2" definitely leaves ring 3 in the clear.
ephemient
Too bad CR0 can't be modified in user-mode. You'll need to get your OS to cooperate if you want to set the AM flag in CR0.
Adam Rosenfield
+2  A: 

I have found a very simple solution on SOF! See: Mis-aligned pointers on x86.

int main(int argc, char **argv)
{
# if defined i386
    /* EDIT: enable AC check */
    asm("pushf; "
    "orl $(1<<18), (%esp); "
    "popf;");
# endif

    char d[] = "12345678";  /* yep! - causes SIGBUS even on Linux-i386 */
    return 0;
}

But I must confess that I do not understand why the assignment

char d[] = "12345678";

is assumed to be mis-aligned?

EDIT:

on the SPARC machine there is no SIGBUS on the line of assignment to char d[].

+3  A: 

To expand on Vokuhila-Oliba's answer looking at the "SOF Mis-aligned pointers on x86." thread it seems that gcc can generate code with mis-aligned memory access. AFAIK you don't have any control over this.

Enabling alignment checks on gcc compiled code would be a bad idea. You risk getting SIGBUS errors for good C code.

ReEdited: Sorry about that

Alexandre Jasmin
@alexandre: I *want* to get these SIGBUS errors. Not in production code of course, but only for debugging.
You risk having SIGBUS for code that __work on SPARC__. It seems that x86 gcc do mis-aligned access in places like variables initialization and I'm not sure you can change that behavior.
Alexandre Jasmin
@alexandre: you are right! My own second answer shows how to check for alignment failures on i386. But this code works perfectly well on Sparc. On i386 it receives SIGBUS. GCCs behavior for i386 can be changed by using e.g. attribute__((aligned(sizeof(char *)))). But it's not possible to do that globally by setting a global GCC flag. Only individually __attribute settings on a data item are possible. And that's too much effort for the project I am working on :-(
@Vokuhila-Oliba even if you *fix* gcc or use another compiler you will have to recompile your libraries or disable alignment checking for each library call your make in your code.
Alexandre Jasmin
@alexandre: "... even if you fix gcc ... you must recompile all libs": good point! I was just warming up my fingers to patch gcc. Thank you for saving me this effort!
+1  A: 

Intel are very big on supporting unaligned loads. If I had to detect such loads on an Intel platform, I think I would have to modify valgrind to treat unaligned loads as errors. Such a modification is not trivial, but valgrind was designed with the idea in mind that users could create new 'tools'. I think a simple modification to the memcheck tool would detect your unaligned references. And the error reporting is really very nice.

Norman Ramsey