Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
103 user(s) are online (59 user(s) are browsing Forums)

Members: 1
Guests: 102

VooDoo, more...

Headlines

 
  Register To Post  

« 1 (2) 3 4 »
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
Ok, the text in 8.8.6 and 5.1.2 of below document is a little bit different.

https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf


Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Corto
Thanks! Tried, and have 2 errors:
1. vertices_packed is not used
2. error: invalid conversion from ‘const u8*’ {aka ‘const unsigned char*’} to ‘char*’ on the "pVPtr = pPtr;", but that one i cast like "pVPtr = (char *)pPtr;".

Through as vertices_packed not used anywhere, i assume they should ?

@Hedeon
Quote:

Ok, the WarpOS kernel had auto correct.


On what cost ? I mean, is it slow things down much ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
Normally, the compiler takes care of this. So the WarpOS autocorrect should only kick in by old and misbehaving apps. you would move the data using general purpose registers and then load them into the correct fp register. Yes. it is slow.

For more info you could look at the GR more carefully and look at the asm output to see if it is

1) integer or floating point
2) which address it is trying to access (and see its alignment)


Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
Are you btw sure OS4 has nothing? I seem to remember asking one of the Frieden brothers to fix an alignment issue of Shogo_WOS while running in WOS emulation on the SAM440. The fix was done inside the alignment exception handler.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Hedeon
Quote:

Are you btw sure OS4 has nothing? I seem to remember asking one of the Frieden brothers to fix an alignment issue of Shogo_WOS while running in WOS emulation on the SAM440. The fix was done inside the alignment exception handler.


At least if it have something, it didn't handle unalignment access there for sure..

Quote:

For more info you could look at the GR more carefully and look at the asm output to see if it is


There is also how crashlog looks like:

[emu_unimplementedUnimplemented opcode
[HAL_DfltTrapHandler] *** WarningFatal exception in task 0x64129C90 (Shell Processetask 0xEFD44600at ip 0x7EAD51E8
Dump of context at 0xEFD17000
Trap type
Alignment exception
Exception Syndrome Register 
(ESR): 0x01000000
Machine State 
(raw): 0x0002F030
Machine State 
(verbose): [Critical Ints on] [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
DSISR01000000  DAR620166D9
Page
0xEFCA73F0 (Virtual0x62016000Physical0x0FB5E000Flags0x 102)
Temporary stack trace:
#0: 0x7EAD51E8
#1: 0x7EAD8D38
#2: 0x7E943BBC
#3: 0x7E89DBC0
#4: 0x7E8A301C
#5: 0x7E8EEF54
#6: 0x7E8C9AA0
#7: 0x7EA5B094
#8: 0x7E8BB978
#9: 0x7E8B2724
#10: 0x7E8AA3F8
#11: 0x7E8A0EDC
#12: in module newlib.library.kmod+0x00002580 (0x01A86280)
#13: in module newlib.library.kmod+0x00003298 (0x01A86F98)
#14: in module newlib.library.kmod+0x000037CC (0x01A874CC)
#15: 0x7E89C924
#16: in module dos.library.kmod+0x0002A5D8 (0x01983EF8)
#17: in module kernel+0x0006B590 (0x0186B590)
#18: in module kernel+0x0006B5D8 (0x0186B5D8)
#19: 0x00000000

Crashed process09.Meshviewer (0x64129C90)
 
07EAD51B4 62337030 00000002 021B28D4 64071764 0182E154 7EAD51B4 61654000
 8
00000004 00000069 00000000 00000038 00000001 639EC8F4 0000049C 63D8C9AC
16
689F17D0 EFD44600 6407D010 00000000 00000004 638E6F70 638E6F48 638E6F58
24
00000007 620166C8 625A7C50 61CE2990 625A5CC8 00000078 62016751 620166D9
CR
39955335   XERC000006F  CTR: 01826C7C  LR7EAD51B4
DSISR
01000000  DAR620166D9

FP0 
FFF80000AE108100 3FFC542C00000000 406BC00000000000 0000000000000000
FP4 
3FF0000000000000 0000000000000000 0000000000000000 3FD287A7636F4361
FP8 
416312D000000000 3FDFFFFFE1016E00 0000000000000000 4039000000000000
FP12
3FF0000000000000 41E0000000000000 6148120531251134 CA7203E48F5618F2
FP16
943105273942CD3C 0F1446FB74B3E2C4 0A86924B503CC930 BB02110F84184813
FP20
683240041C2A0862 8220716F9592D154 1660825EFD40E830 0900002EF334C827
FP24
993E64BE746B61D0 94723E0661FAD873 2844ABA31A49312E 1114DEB6D0B6D4B1
FP28
89FB1296DD96BC73 892C020491C2A00E 0315FA0B102AD817 D253605A4E88AD7C
FPSCR
AE108100

Disassembly of crash site
:
 
7EAD51D83929FFFF   subi              r9,r9,1
 7EAD51DC
5529043E   rlwinm            r9,r9,0,16,31
 7EAD51E0
1D29000F   mulli             r9,r9,15
 7EAD51E4
7FC9F214   add               r30,r9,r30
>7EAD51E8C03F0000   lfs               f1,0(r31)
 
7EAD51EC3BFF000F   addi              r31,r31,15
 7EAD51F0
4BDE0389   bl                0x7E8B5578
 7EAD51F4
D0210220   stfs              f1,544(r1)
 
7EAD51F8C03FFFF5   lfs               f1,-11(r31)
 
7EAD51FC81210220   lwz               r9,544(r1)


In GR, i can read that:

CrashType: alignemnt
Function Offset: 0x00000164

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
lfs means load fpu single (so float32) from 0(r31) which is 0x620166D9 which means on a single byte aligned address.

I cannot see if that is due to the struct you showed with the u8 at the start.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
The

# if (__GNUC__ > 4 ) || ((__GNUC__ == 4 ) && (__GNUC_MINOR__ >= 7))
# pragma pack( push, packing )
# pragma pack( 1 )

Tells me that the structs will be byte aligned. Which is not a good idea for PPC.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Hedeon
Maybe for sake of test just put theere 2 or 4 ?:)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
You could do two things

1) Put the floats at the start of the struct
2) Make it 4 (but that is actually the default so removing it might be better. 2 will still give alignment trouble for fpu.

Why is pragma pack(1) needed?

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Hedeon
Tried firstly move floats at start of struct : same crash
Tried then change pragma pack(1) to pragma pack(4), it says "sorry wrong file format", so i assume all code based there in meaning that there is pragma pack(1) (dunno why they choice that at all, maybe exactly to align structs to not be 3, 5, 7 or whatever, but always be diveded on /2).


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
Ok, Now i've re-read everything...

The data presented is a binary block? So everything is fixed already? And the struct is a representation of this binary block?

So salass is more right towards the solution (sorry).

You should try it again and see if the GR is different regarding the asm.

In the quick reads I did I think I read for example that lwbrx also gives an alignment error on byte aligned addresses. So maybe with his suggestions you got a different alignment exception.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Hedeon
Quote:

The data presented is a binary block? So everything is fixed already? And the struct is a representation of this binary block?


Yeah, its just load() function of .ms3d file and parsing it.

What i want to understand now, is we face there 2 different unaligned memory problems or its just one, which just happens in different conditions, one was when we do "f32 framesPerSecond = *(float*)pPtr;", so reading the floating point value from an unaligned pointer. And second one are the same reading of unaligned pointer when we have any floats in the structure which is packed, right ?

I mean, i want to note some simple rulz to follow later. Like, if any structure in code have floats, and then pragma_packed, then its no-go for PPC (is it correct?).

For example, there is .md2 loader, which also have floats inside of structs and that one didn't crash on our side:

https://sourceforge.net/p/irrlicht/cod ... ht/CMD2MeshFileLoader.cpp

See right at top there is structure of such kind:

struct SMD2Frame
    
{
        
f32    scale[3];           // first scale the vertex position
        
f32    translate[3];       // then translate the position
        
c8    name[16];           // the name of the animation that this key belongs to
        
SMD2Vertex vertices[1]; // vertex 1 of SMD2Header.numVertices
    
PACK_STRUCT;


And that loader didn't crash surely (maybe it loads by bytes then as Salas00 says ? See CMD2MeshFileLoader::loadFile there)


Edited by kas1e on 2019/10/23 15:11:33
Edited by kas1e on 2019/10/23 15:12:36
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Not too shy to talk
Not too shy to talk


See User information
@kas1e

Oops, I am really sorry, I mixed 2 variants ...

You can comment the line:
MS3DVertexPacked *vertices_packed = (MS3DVertexPacked *)pPtr;


Note that you certainly will also see a crash at:
f32 framesPerSecond = *(float*)pPtr;


Again, you can convert it replacing the line by this block:
f32 framesPerSecond;
    
HybridFloat tmpfloat;

    
tmpfloat.cvalue[3] = pPtr[0];
    
tmpfloat.cvalue[2] = pPtr[1];
    
tmpfloat.cvalue[1] = pPtr[2];
    
tmpfloat.cvalue[0] = pPtr[3];
    
    
framesPerSecond tmpfloat.fvalue;


Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
That loader you show has everything aligned. That is why it does not crash. The floats are at the top so start at 0. The other struct has a u8 at the top so the first float starts at 1 (and therefore is misaligned for the PPC FPU).

Loading it as an integer and then convert it to float should work (the examples by salass and corto). You said they also crashed but i'd like to see also the GR output there. I am suspecting it is a different alignment issue (not FPU).

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Corto
Is that the variant you mean then ?:
MS3DVertex *vertices;
    
HybridFloat tmpfloat;
    
char *pVPtr;
    
pVPtr = (char *)pPtr// address of the first packed vertex in memory
    
    
pPtr += sizeof(MS3DVertexPacked) * numVertices;
    if (
pPtr buffer+fileSize)
    {
        
delete [] buffer;
        
os::Printer::log("Loading failed. Corrupted data found."file->getFileName(), ELL_ERROR);
        return 
false;
    }
    for (
u16 tmp=0tmp<numVertices; ++tmp)
    {
#ifdef __BIG_ENDIAN__
        // Read per byte with swapping and fill the 3 vertices in the final structure
        // pVPtr[0] is ignored, it contains the char field Flags
        
tmpfloat.cvalue[3] = pVPtr[1];
        
tmpfloat.cvalue[2] = pVPtr[2];
        
tmpfloat.cvalue[1] = pVPtr[3];
        
tmpfloat.cvalue[0] = pVPtr[4];
        
vertices[tmp].Vertex[0] = tmpfloat.fvalue;
        
tmpfloat.cvalue[3] = pVPtr[5];
        
tmpfloat.cvalue[2] = pVPtr[6];
        
tmpfloat.cvalue[1] = pVPtr[7];
        
tmpfloat.cvalue[0] = pVPtr[8];
        
vertices[tmp].Vertex[1] = tmpfloat.fvalue;
        
tmpfloat.cvalue[3] = pVPtr[9];
        
tmpfloat.cvalue[2] = pVPtr[10];
        
tmpfloat.cvalue[1] = pVPtr[11];
        
tmpfloat.cvalue[0] = pVPtr[12];
        
vertices[tmp].Vertex[2] = - tmpfloat.fvalue;

        
// Go to the next vertex structure
        
pVPtr += sizeof(struct MS3DVertexPacked);
#else
        
vertices[tmp].Vertex[2] = -vertices[tmp].Vertex[2];
#endif
    
}


If so, it crashes on tmpfloat.cvalue[1] = pVPtr[7]; line..

And on compiling time it also says that: "vertices" may be used uninitialized in this function.


Quote:

Note that you certainly will also see a crash at:
f32 framesPerSecond = *(float*)pPtr;


Yeah, i fixed it as Salas00 show before:
union {
    
u32 u;
    
float f;
tmp;
tmp.= *(u32*)pPtr;
f32 framesPerSecond tmp.f;



That was the first alignment issue i crash on, and that one which we have now are second one.

@Hedeon

I still can't get it .. Is actual problem is not that packed struct have floats, but that those floats not at begining of structure ?

Should't we then just for every structure move all floats at top, and then, before each structure doing some "dumb" structure with empty u8 , i mean instead of original doing it all like this:

namespace {
// File header
struct MS3DHeader
{
    
char ID[10];
    
int Version;
PACK_STRUCT;


struct dumb_endian1 {
    
u8 dumbo1;
PACK_STRUCT;
struct MS3DVertex
{
    
float Vertex[3];
    
u8 Flags;
    
char BoneID;
    
u8 RefCount;
PACK_STRUCT;


// Triangle information
struct dumb_endian2 {
    
u8 dumbo;
PACK_STRUCT;
struct MS3DTriangle
{
    
float VertexNormals[3][3];
    
float S[3], T[3];
    
u16 Flags;
    
u16 VertexIndices[3];
    
u8 SmoothingGroup;
    
u8 GroupIndex;
PACK_STRUCT;

// Material information
struct dumb_endian3 {
    
u8 dumbo;
PACK_STRUCT;
struct MS3DMaterial
{
    
float Ambient[4];
    
float Diffuse[4];
    
float Specular[4];
    
float Emissive[4];
    
float Shininess;    // 0.0f - 128.0f
    
float Transparency;    // 0.0f - 1.0f
    
char Name[32];
    
u8 Mode;    // 0, 1, 2 is unused now
    
char Texture[128];
    
char Alphamap[128];
PACK_STRUCT;

// Joint information
struct dumb_endian4 {
    
u8 dumbo;
PACK_STRUCT;
struct MS3DJoint
{
    
float Rotation[3];
    
float Translation[3];
    
u8 Flags;
    
char Name[32];
    
char ParentName[32];
    
u16 NumRotationKeyframes;
    
u16 NumTranslationKeyframes;
PACK_STRUCT;

// Keyframe data
struct dumb_endian5 {
    
u8 dumbo;
PACK_STRUCT;
struct MS3DKeyframe
{
    
float Time;
    
float Parameter[3];
PACK_STRUCT;

// vertex weights in 1.8.x
struct MS3DVertexWeights
{
    
char boneIds[3];
    
u8 weights[3];
PACK_STRUCT;

// end namespace


I tried it like this with original code, and it still crashes on the same "for (u16 tmp=0; tmp<numVertices; ++tmp)" loop then with alignemnt crashlog i show before.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Just popping in
Just popping in


See User information
Yes, normally with packed structures you would put all floats at the top. But here the input is already fixed. So the float is actually at offset 1 in that binary data. So in memory the loaded data will always have the float at offset 1. And of course, in this cause you might load the data in at offset 3 so the u8 flag will be at offset 3 and then the float at offset 4 (and add 3 dummy bytes at the start of the struct, and allocate a slightly bigger buffer) but then other loaders would give errors probably.

So going the integer way and then convert should do the trick. I am not sure why it is still crashing when you do that. I then need to see the asm output for each case.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Hedeon
Quote:

Yes, normally with packed structures you would put all floats at the top. But here the input is already fixed. So the float is actually at offset 1 in that binary data. So in memory the loaded data will always have the float at offset 1. And of course, in this cause you might load the data in at offset 3 so the u8 flag will be at offset 3 and then the float at offset 4 (and add 3 dummy bytes at the start of the struct, and allocate a slightly bigger buffer) but then other loaders would give errors probably.


Yeah of course you can't just swap the floats to any arbitrary place in strucutre as it will mess the data for sure.

Quote:

but then other loaders would give errors probably.


Nah, all the loaders have all their own code. So doing anything with one loader have no inpact on other ones.

Quote:

So going the integer way and then convert should do the trick. I am not sure why it is still crashing when you do that. I then need to see the asm output for each case.


It crashes because i don't do integer/convert way :) The only conversion i do at moment was about "f32 framesPerSecond = *(float*)pPtr;" and that one works now. The next crash come from those float-structs and reading from them , and Corto's way probably still have some bug, as it just crashes in the middle of copy-buffering.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@All
Found interesting article about alignment issues on ibm's site:
https://developer.ibm.com/articles/pa-dalign/

There is interesting part:

Quote:

The PowerPC takes a hybrid approach. Every PowerPC processor to date has hardware support for unaligned 32-bit integer access. While you still pay a performance penalty for unaligned access, it tends to be small.

On the other hand, modern PowerPC processors lack hardware support for unaligned 64-bit floating-point access. When asked to load an unaligned floating-point number from memory, modern PowerPC processors will throw an exception and have the operating system perform the alignment chores in software. Performing alignment in software is much slower than performing it in hardware.


Its says that every PPC cpu has hardware support for unaligned 32-bit integer access. What about other ones ? 64 one for example ?

It also says that modern powerpc have issues with unaligned 64bit floats, but then what about 32 ? (as we can see 32 ones fail too).

And funny thing that "operating system perform the handling of unaligned memory access in the software", while if we have crashes , it didn't sounds like amigaos4 kernel handle those exceptions in software, but just crashes instead.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: type of crash: alignment exeption, how to fix ?
Not too shy to talk
Not too shy to talk


See User information
@kas1e

I'm sorry again but I wrote the code being at work earlier today ... The compiler is right about uninitialized vertices, I omitted to allocate them!

MS3DVertex *vertices;
...
vertices = new MS3DVertex[numVertices];

And don't forget to free them at the end of the function:

delete [] vertices;

I hope that will work ... In any case, don't modify the organization of structures that match a binary chunk loaded from data file.

Go to top
Re: type of crash: alignment exeption, how to fix ?
Home away from home
Home away from home


See User information
@Corto
Yeah, that works now, thanks !

As expected through crashed on the next for() loop where it tries to read triangles, which use that structure:

// Triangle information
struct MS3DTriangle
{
    
u16 Flags;
    
u16 VertexIndices[3];
    
float VertexNormals[3][3];
    
float S[3], T[3];
    
u8 SmoothingGroup;
    
u8 GroupIndex;
PACK_STRUCT;


Will try to do it the way you show for all other parts.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 (2) 3 4 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project