Programming

Originally Posted by Corona688

That forces alignment with a #pragma, otherwise, that'd be extremely difficult.

He didn't mention that about his code, but you're right, it could be something to look for.

-xmemalign=ab
(SPARC) Use the -xmemalign option to control the
assumptions the compiler makes about the alignment of
data. By controlling the code generated for potentially
misaligned memory accesses and by controlling program
behavior in the event of a misaligned access, you can
more easily port your code to SPARC.

Specify the maximum assumed memory alignment and
behavior of misaligned data accesses. There must be a
value for both a (alignment) and b (behavior). a speci-
fies the maximum assumed memory alignment and b speci-
fies the behavior for misaligned memory accesses.
For memory accesses where the alignment is determinable
at compile time, the compiler generates the appropriate
load/store instruction sequence for that alignment of
data.

For memory accesses where the alignment cannot be
determined at compile time, the compiler must assume an
alignment to generate the needed load/store sequence.

For memory accesses where the alignment is determinable
at compile time, the compiler generates the appropriate
load/store instruction sequence for that alignment of
data.

For memory accesses where the alignment cannot be
determined at compile time, the compiler must assume an
alignment to generate the needed load/store sequence.

If actual data alignment at runtime is less than the
specified alignment, the misaligned access attempt (a
memory read or write) generates a trap. The two possi-
ble responses to the trap are as follows:

o The OS converts the trap to a SIGBUS signal. If the
program does not catch the signal, the program aborts.
Even if the program catches the signal, the misaligned
access attempt will not have succeeded.

o The OS handles the trap by interpreting the
misaligned access and returning control to the program
as if the access had succeeded normally.

Values

Accepted values for a are:

1 Assume at most 1 byte alignment.

2 Assume at most 2 byte alignment.

4 Assume at most 4 byte alignment.

8 Assume at most 8 byte alignment.

16 Assume at most 16 byte alignment.

Accepted values for b are:

i Interpret access and continue execution.

s Raise signal SIGBUS.

f For variants of -xarch=v9 only. Raise signal
SIGBUS for alignments less than or equal to
4, otherwise interpret access and continue
execution. For all other -xarch values, the f
flag is equivalent to i.

You must also specify -xmemalign whenever you want to
link to an object file that was compiled with the value
of b set to either i or f. For a complete list of com-
piler options that must be specified at both compile
time and at link time, see the C User's Guide.

Defaults

The default for all SPARC v9 architectures is
-xmemalign=8s. Specifying -xmemalign is equivalent to
specifying -xmemalign=1i.

Originally Posted by jim mcnamara

Solaris supports memalign() - a malloc variant that allows specification of alignments on a per object basis. We have had to take that approach with some code.

For memory accesses where the alignment cannot be
determined at compile time, the compiler must assume an
alignment to generate the needed load/store sequence.

Originally Posted by achenle

The problem comes from using a structure in such a way that a member that has a strict alignment is offset from the beginning of the structure by an amount that causes the alignment to be wrong.

It's pretty much the archetype of how to get a SIGBUS error on SPARC.

Originally Posted by fpmurphy

Code:

struct _a
{
    int _a1;
    uint64_t _a2;
}

Please explain how you come to the conclusion that the 2nd member of the structure require strict alignment. I do not see that requirement.