Asking around in #llvm irc, people say there that in Clang a syntax something like "uint32_t __attribute__((align(1))) *pointer = xxx;" could be used to signal that deferences through that particular pointer should be treated as unaligned. That should result in unaligned reference in the LLVM bytecode, which Emscripten is able to pick up and generate an unaligned load/store, even when no special link flags are used. That could be worth a try, e.g. typedeffing/defining a pointer type unaligned_u32_ptr or similar?
2014-05-08 16:20 GMT+03:00 Christoph Husse <[email protected]>: > Hmm I don't know :D. I will try it if my current approach fails. I > notices from what Emscripten reported so far that the CPU emulator I > am trying to compile conveniently pipes all memory accesses through > macros that do the little/big endian handling. So basically I am now > trying to hook a warn&fix template into those macros and hope that > there are not any other misaligned accesses done except through those > macros. > > On Thu, May 8, 2014 at 3:18 PM, Jukka Jylänki <[email protected]> wrote: > > Oh, I misread Module.getValue and Module.setValue that they'd do > unaligned > > accesses. Well, what happens if you combine that modification with -s > > UNALIGNED_MEMORY=1? Are those two incompatible? > > > > > > 2014-05-08 15:48 GMT+03:00 Christoph Husse <[email protected] > >: > > > >> As this was the initial problem. The application does not work without > >> UNALIGNED_MEMORY. > >> > >> On Thu, May 8, 2014 at 2:47 PM, Christoph Husse > >> <[email protected]> wrote: > >> > Well its a nice thought but the issue will most likely be that then > >> > the application gets broken and doesn't do what it would normally do > >> > ;). I need the UNALIGNED_MEMORY fix in combination with a notification > >> > for actual unaligned accesses. > >> > > >> > On Thu, May 8, 2014 at 2:11 PM, Jukka Jylänki <[email protected]> > wrote: > >> >> Hmm, looking at the current code, as a quick manual fix you could try > >> >> compiling with -s SAFE_HEAP=1, and then going to the output file and > >> >> editing > >> >> the generated functions SAFE_HEAP_LOAD and SAFE_HEAP_STORE to just > >> >> 'console.error()' instead of 'abort()'. Does that work? > >> >> > >> >> > >> >> 2014-05-08 14:39 GMT+03:00 Christoph Husse > >> >> <[email protected]>: > >> >> > >> >>> EWWW!!! > >> >>> > >> >>> Looks like I have alignment issues (and well... my code too xD). > >> >>> > >> >>> So I have now worked a lot on the sources to have the same types on > >> >>> all platforms, compile by using a single "cpp" file, etc... And I > also > >> >>> got the emscripten options like SAFE_HEAP really to work. > >> >>> After executing the thing with Node.js I see that I have unaligned > >> >>> reads & writes. using UNALIGNED_MEMORY=1 fixes it but its slow > because > >> >>> it generates the machinery for all loads/stores while only few of > them > >> >>> are unaligned. > >> >>> > >> >>> Is there a way to use UNALIGNED_MEMORY while at the same time > listing > >> >>> all the places where it actually encountered an unaligned > load/store? > >> >>> That would be really helpful because right now I would have to find > an > >> >>> offending line, recompile, restart, find the next offending line, > >> >>> etc... This would be extremely time consuimg especially since one > >> >>> iteration may well take over 5 minutes... > >> >>> > >> >>> Any ideas? > >> >>> > >> >>> On Wed, May 7, 2014 at 9:31 AM, Jukka Jylänki <[email protected]> > >> >>> wrote: > >> >>> > Emscripten/JS is a little endian platform, just like X86, so the > >> >>> > same > >> >>> > code > >> >>> > paths should work for JS and X86. It is ok to test for this at > >> >>> > runtime > >> >>> > and > >> >>> > do different things based on the result. Just make sure that the > JS > >> >>> > platform > >> >>> > correctly takes the little endian path and that should be all good > >> >>> > there. > >> >>> > > >> >>> > > >> >>> > 2014-05-07 9:49 GMT+03:00 Christoph Husse > >> >>> > <[email protected]>: > >> >>> >> > >> >>> >> Okay thanks for that input. Gonna try it today. Maybe SAFE_HEAP > was > >> >>> >> off > >> >>> >> because I didn't get any output. > >> >>> >> > >> >>> >> Besides what you have recommended, I was working on "un-stding" > my > >> >>> >> sources > >> >>> >> yesterday with success. There are NO standard library headers and > >> >>> >> also > >> >>> >> no > >> >>> >> memory allocations (everything froma static buffer) and no > >> >>> >> conditional > >> >>> >> compilation macros... All types are the same size and sign on all > >> >>> >> platforms > >> >>> >> now. > >> >>> >> > >> >>> >> Only left is the big/little endian thing. Do you know if it is > okay > >> >>> >> to > >> >>> >> do > >> >>> >> runtime code switches based on endianess? The code needs to take > >> >>> >> different > >> >>> >> paths depending on endianess... Its a very low level CPU > emulator, > >> >>> >> so > >> >>> >> there > >> >>> >> is a lot of very platform specific low-level code in it. > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> You received this message because you are subscribed to the > Google > >> >>> >> Groups > >> >>> >> "emscripten-discuss" group. > >> >>> >> To unsubscribe from this group and stop receiving emails from it, > >> >>> >> send > >> >>> >> an > >> >>> >> email to [email protected]. > >> >>> >> > >> >>> >> For more options, visit https://groups.google.com/d/optout. > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > You received this message because you are subscribed to a topic in > >> >>> > the > >> >>> > Google Groups "emscripten-discuss" group. > >> >>> > To unsubscribe from this topic, visit > >> >>> > > >> >>> > > >> >>> > > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe > . > >> >>> > To unsubscribe from this group and all its topics, send an email > to > >> >>> > [email protected]. > >> >>> > For more options, visit https://groups.google.com/d/optout. > >> >>> > >> >>> -- > >> >>> You received this message because you are subscribed to the Google > >> >>> Groups > >> >>> "emscripten-discuss" group. > >> >>> To unsubscribe from this group and stop receiving emails from it, > send > >> >>> an > >> >>> email to [email protected]. > >> >>> For more options, visit https://groups.google.com/d/optout. > >> >> > >> >> > >> >> -- > >> >> You received this message because you are subscribed to a topic in > the > >> >> Google Groups "emscripten-discuss" group. > >> >> To unsubscribe from this topic, visit > >> >> > >> >> > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe > . > >> >> To unsubscribe from this group and all its topics, send an email to > >> >> [email protected]. > >> >> For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "emscripten-discuss" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "emscripten-discuss" group. > > To unsubscribe from this topic, visit > > > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe > . > > To unsubscribe from this group and all its topics, send an email to > > [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
