How to catch data-alignment faults on x86 (aka SIGBUS on Sparc)

Question

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.

It sounds like running your tests in `qemu` (which can target SPARC) may be faster than running on actual hardware? — ephemient, Dec 18 '09 at 18:21
I have never tried qemu, but that sounds interesting. Does that work without some kind of a "System-ROM" or something similar? — , Dec 18 '09 at 19:16
The QEMU project bundles `openbios-sparc`, which is enough to let `qemu-system-sparc` like a real machine. There is also `qemu-sparc` which runs only a single Linux executable under emulation, translating syscalls to the native kernel. — ephemient, Dec 18 '09 at 22:36
Note that `qemu-user-*` (which lets you "just" run an executable for a different architecture as opposed to `qemu-system-*` which emulates a whole VM) doesn't emulate/send memory alignment faults that happen on the target architecture. — Anon, Jul 28 '18 at 15:31

score 9 · Answer 1 · 2009-12-19T13:24:23.643

9

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

edited Dec 19 '09 at 13:24

answered Dec 18 '09 at 17:54

Unfortunately, user-mode code all runs in ring 3; the above won't generate exceptions. – ephemient Dec 18 '09 at 18:06
I lack knowledge about these CPU "rings". But if a normal program uses ring-3 then it would be good enough. – Dec 18 '09 at 18:23
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 Dec 18 '09 at 22:39
1

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 Dec 19 '09 at 05:49

score 4 · Accepted Answer · edited May 23 '17 at 10:34

4

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

edited May 23 '17 at 10:34

Community

1
1

answered Dec 18 '09 at 23:32

Alex Jasmin

39,094
7
77
67

@alexandre: I *want* to get these SIGBUS errors. Not in production code of course, but only for debugging. – Dec 19 '09 at 11:05
3

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. – Alex Jasmin Dec 19 '09 at 15:13
@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 :-( – Dec 19 '09 at 22:25
1

@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. – Alex Jasmin Dec 19 '09 at 23:27
@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! – Dec 20 '09 at 05:03

score 3 · Answer 3 · edited May 23 '17 at 11:55

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[].

score 3 · Answer 4 · answered Dec 19 '09 at 00:05

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.

score 1 · Answer 5 · answered May 27 '17 at 08:58

Many years later: if your gcc/clang is new enough (GCC 4.9, clang 3.3?) you may be able to build your code with the undefined behaviour sanitizer (-fsanitize=undefined) to get warnings about misaligned accesses on a given platform (but bear in mind different platforms have different alignment requirements, different compilers will choose different layouts etc). See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html and https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ for details.

Mark Ransom · Answer 6 · 2009-12-19T05:02:08.173

0

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.

edited Dec 19 '09 at 05:02

answered Dec 18 '09 at 17:29

Mark Ransom

299,747
42
398
622

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. – Dec 19 '09 at 22:35

How to catch data-alignment faults on x86 (aka SIGBUS on Sparc)

6 Answers6

Linked