In a program developed by me my tester (currently I have no working Amiga) reported an alignment exception in a totally innocent position. Looking at the crashlog it seems it did not like the alignment of a data structure. Now if I remember correctly the Sam (he tested on a Sam) requires data structures 32 Bit aligned.

Now I *think* to remember there was some ENV Variable to set if an alignment exception should cause a crash or not (or was this with WarpOS? Maybe I am confusing things...). Can somebody clear this up for me?

I am also trying right now to compile my application with -mstrict-align, maybe this would help?

Any comments welcome.

This is what caused the alignment exception:

if (config->xoffset != 0)
{
settings.xoffset = config->xoffset;
}

settings is a local variable, config is a pointer variable pointing to something inside a structure inside a structure inside a pointer parameter.

It's just been some years since my last Amiga developments, some years before I'd probably have known my own answers

MagicSN

@MagicSN

Yes but is the config pointer correctly set?

And did you or some one else allocate the required amount of memory to hold the full config structure.
AllocVec( sizeof(struct config) ,MEM_ANY)

Last edited by NutsAboutAmiga on 05-Jun-2009 at 08:10 AM.
Last edited by NutsAboutAmiga on 05-Jun-2009 at 08:07 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

As it works on Linux, Windows and MorphOS (it is portable, non-Amiga-specific code) I doubt this is the problem.

Steffen

@MagicSN

To me it sounds like a symptom of a bigger problem with the code.

_________________
Playstation Network ID: xeron6

@xeron

Then you are wrong, plainly spoken (BTW: Older versions of the same code work fine, and there hasn't really been changes to this part of the code - the same code also compiles
on dozens of OS'es - though this of course is a bad argument).

I BTW checked again, there are proper checks about the
data structures (like it being != null). The only problem is that it seems not to be properly aligned to 32 Bit Boundary. It is NOT a DSR or a null pointer exception, it is an
ALIGNMENT exception.

Can someone PLEASE answer my original question:

- Is there some way to make an alignment exception not crash (AFAIR there
was some way, but not sure anymore) ?
- How exactly does -mstrict-align work? To what boundary does it align?

MagicSN

@MagicSN

You don't want alignment exceptions not to crash. They are an error that should be fixed.

How are the relevant structures defined? How are the relevant structures allocated?

_________________
Playstation Network ID: xeron6

@MagicSN

Hi,

I had the same problem when developing Digital Universe with the latest SDK. Older SDKs worked but the latest one did not.

The answer I was given from the SDK experts is:

Quote:

OK, we finally figured out what is happening and it is anAmigaOS-specific GCC compiler bug.

Quote:

The root cause of the trouble is the pack(2) as you suspected all along. However, our GCC should have been created withthe -mstrict-align option to force strict alignments of floatingpoint types which makes the code run faster (alignment is good)at the expense of storage space.A bug has been filed against our version of GCC.

Quote:

So add the -mstrict-align optionand your code should still compile and run without this problem. This enables the optimizer to do its job without worry.

So currently add the -mstrict-align in your makefiles when compiling for OS4, in a future SDK you should be able to leave this out as it will be on by default.

Hope this helps.



Bill.

@BillE

He is using -mstrict-align

_________________
Playstation Network ID: xeron6

@xeron

Quote:

He is using -mstrict-align

It looks more as if the question is should he use it, and the answer is Yes.

@BillE

Thanks, this helps a lot. I am now compiling a version with -mstrict-align and will make this available to my tester. This also explains why I did not have the problem with older
versions. Before I used a very old version of the SDK (where the bug did not yet exist, I guess).

@xeron: Sorry, this is not possible. This code has been compiled for dozens of platforms tested by many many people, I really doubt there is a problem there. Especially as it works fine in the older version (compiled by an older SDK). Sure, there were some code changes since the older version, but this part of the code did not really change.

MagicSN

@xeron

No, I am not. At least not in the version on the testers machine. I compiled it in the meanwhile with strict-align but did not give it to him yet (also was unsure if strict-align would make any difference).

When Compiling with -mstrict-align there are some warnings about "casts changing alignment" in the code.Are they any worry? (It is appearently enabled by -Wcast-align in the makefile, I disabled this for now, so I can enable -mstrict-align and still compile with -Werror).

Compiler is 4.2.0 from 22th May 2007, according to ppc-amigaos-gcc -v BTW.

MagicSN

Last edited by MagicSN on 05-Jun-2009 at 09:26 AM.
Last edited by MagicSN on 05-Jun-2009 at 09:24 AM.

@MagicSN
The ENV var setting for alignment exceptions was in WarpOS, not in OS4. If you have problems with alignment, you should use MorphOS. It handles all unaligned access exceptions on PowerPC. (Just like Linux and OS X does. But, true there are other systems, like NetBSD, which doesn't, like OS4.)

BTW, IIRC earlier OS4 SDK had some problems with binutils (the linker specifically, i think), which could cause misaligned global data structures in the executable. At least i ran into this problem during my Free Pascal port, but back then, the cause was unknown. So i worked it around in the code generator. Later (after SAM appeared, which has much stricter alignment) i was told, that a bug which might be related to this was discovered in the binutils port, and it was fixed in the latest SDK.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@Chain-Q

Well, I am trying if -mstrict-align will help which I am now told by several people (and also read a post on a non-Amiga-related group where someone fixed a similar issue on a CPU like used in the Sam by -mstrict-align, so let's hope it helps).

Latest SDK - well, I am using a cross-compiler, not the native OS 4 set of tools. The one I use is from 2007 still (version 4.2.0). Latest Includes+Libs, though.

And ah, then I mixed that ENV stuff up with the stuff back in WarpOS-times.

MagicSN

Last edited by MagicSN on 05-Jun-2009 at 10:41 AM.

@Chain-Q

As long as you can enable alignment exception logging of some sort, I guess it's ok for the OS to handle the exceptions in a nicer way than just having the application crash on you, although it's better to fix the alignment problem and avoid the overhead of the exception handler, which is kind of hard if you never get to know about the exception in the first place...

@AmiDog

As a developer, i know i'd rather have the crash.

_________________
Playstation Network ID: xeron6

@MagicSN

it is strange this kind of exception.
did you try #pragma pack(1) on struct definition? have you try to add a dummy variable to align the other one?

_________________
http://www.amigasoft.net

@MagicSN

Just in case of, there are the utilitybase.com site, for programming questions about the amiga (but I'm sure you know that

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@BillE
Do you know if this bug could affect 64-bit (long long) values? And whether -mstrict-align would help?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

I hope -mstrict-align will help. And no, has nothing to do with long long.

MagicSN

Some more input: The problem was related to this code:

typedef struct _screen_config screen_config;
struct _screen_config
{
int type; /* type of screen */
int width, height; /* default total width/height (HTOTAL, VTOTAL) */
rectangle visarea; /* default visible area (HBLANK end/start, VBLANK end/start) */
UINT8 oldstyle_vblank_supplied; /* MDRV_SCREEN_VBLANK_TIME macro used */
attoseconds_t refresh; /* default refresh period */
attoseconds_t vblank; /* duration of a VBLANK */
bitmap_format format; /* bitmap format */
float xoffset, yoffset; /* default X/Y offsets */
float xscale, yscale; /* default X/Y scale factor */
};

As you can clearly see the structure is not 32 Bit aligned starting at "refresh" (attoseconds_t is a long long, bitmap_format also a 32 Bit value, and rectangle consists of 4 int's BTW). I *did* recompile with -mstrict-align (I forgot to add -mstrict-align to the linking command, is this a problem? Or is it only needed on compiling) and it still happened.

Now I am trying a different thing, including 3 Pad-Bytes after the UINT8 (well, let's hope there are not more such things...).

Any input welcome


And I would be interested in a non-Sam-tester, to see if the problem only happens on Sam! The person would need a ftp site, though, as the file is too big for email.

Steffen