| 00:18.04 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 01:07.36 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 01:22.20 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 01:27.32 | *** join/#edev SpeedEvil1 (~user@tor/regular/SpeedEvil) |
| 01:46.38 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 02:11.07 | *** join/#edev SpeedEvil (1000@tor/regular/SpeedEvil) |
| 03:46.08 | *** join/#edev mbuf (~user@118.102.130.34) |
| 03:47.15 | *** join/#edev JViz (~JViz@cpe-024-163-014-080.triad.res.rr.com) |
| 04:02.33 | *** join/#edev n900evil (~Speedevil@tor/regular/SpeedEvil) |
| 09:06.17 | *** join/#edev mbuf (~user@118.102.130.34) |
| 09:10.56 | *** join/#edev kpierre (~kpierre@n3.jabber.d6.hsdnsrv.net) |
| 09:11.27 | *** part/#edev kpierre (~kpierre@n3.jabber.d6.hsdnsrv.net) |
| 10:46.38 | *** join/#edev sndcrb (~sndcrb@easy-ff00c200-144.dhcp.inet.fi) |
| 11:18.37 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 11:41.36 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 13:47.09 | *** join/#edev rasker (~Rehan@89-168-90-194.dynamic.dsl.as9105.com) |
| 13:52.42 | *** join/#edev ska (~ska@cpe-66-68-100-194.austin.res.rr.com) |
| 14:13.05 | *** join/#edev roxfan (dunno@91.180.239.62) |
| 14:44.44 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 15:05.30 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 15:05.30 | *** mode/#edev [+o GPSFan] by ChanServ |
| 16:04.55 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 16:06.12 | *** join/#edev n900evil (~Speedevil@tor/regular/SpeedEvil) |
| 16:18.02 | *** join/#edev n900evil (~Speedevil@tor/regular/SpeedEvil) |
| 16:52.34 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 18:05.05 | *** join/#edev florian (~fuchs@82.113.121.164) |
| 18:05.05 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:16.21 | *** join/#edev kpierre (~kpierre@n3.jabber.d6.hsdnsrv.net) |
| 18:16.45 | *** part/#edev kpierre (~kpierre@n3.jabber.d6.hsdnsrv.net) |
| 18:19.32 | *** join/#edev prpplague (~prpplague@ppp-70-249-148-152.dsl.rcsntx.swbell.net) |
| 18:41.58 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 20:07.53 | *** join/#edev kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 20:18.02 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 20:18.02 | *** mode/#edev [+o GPSFan] by ChanServ |
| 20:32.14 | *** join/#edev m4D_ (kvirc@ppp91-77-178-22.pppoe.mtu-net.ru) |
| 20:32.45 | m4D_ | hello. i'am writing some app for armv5te-xscale wince. i'm stuck with it crashing on code: u8 header[40]; fread(...); u32 var = *(u32 *)(header + 10); any ideas? possible alignment error? |
| 20:32.57 | m4D_ | replacing it with memcpy(&var, header + 10, 4) works ok. btw, compiling it with emvc4 works ok too. but gcc-compiled code fails ( |
| 20:37.20 | roxfan | maybe this will help http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment |
| 20:40.32 | m4D_ | roxfan: thanks, but what i seek - is how to compile with arm-mingw32ce a lot of code without adding any modifications? (as i said, emvc4 compiles ok, but gcc's code is 2x faster) |
| 20:43.22 | davidc___ | m4D_: yeah, looks like an alignment problem |
| 20:44.36 | m4D_ | davidc___: but why then the code, generated with emvc4 works ok? isn't alignments behaviour altered by cpu flag but not a compiler? i haven't found any gcc-flags to "auto-fix optimization" of alignment errors |
| 20:46.12 | davidc___ | m4D_: AFAIK, unaligned memory accesses are always unallowable on the xscale |
| 20:46.18 | davidc___ | *disallowed |
| 20:46.57 | davidc___ | m4D_: technically; the problem is your code is wrong. emvc4 just happens to make a working binary out of it - possibly due to random chance |
| 20:47.04 | roxfan | check the disassembly |
| 20:47.15 | roxfan | maybe evc does byte copy |
| 20:47.34 | m4D_ | ok, i need arm disasm.. |
| 20:47.36 | davidc___ | or it just lays out the variables on the stack a bit different, such that header+10 ends up being byte aligned |
| 20:48.19 | davidc___ | also u32 var = *(u32 *)(header + 10); is non-endian safe |
| 20:48.21 | roxfan | you can enable listing generation |
| 20:49.47 | davidc___ | m4D_: the endian safe way to do it [assuming header is little-endian] is (header[13] << 24) | (header[12] << 16) | (header[11] << 8) | header[10] |
| 20:53.20 | roxfan | hm, apparently linux kernel provides get_unaligned() and put_unaligned() macros |
| 20:59.05 | m4D_ | ok, here's disasm: http://pastebin.com/QEsqW0gs - what i get from it is that i absolutely don't understand arm-asm) |
| 21:00.36 | davidc___ | m4D_: is that from gcc or emvc4? |
| 21:00.51 | m4D_ | davidc___: that's emvc4 |
| 21:02.12 | davidc___ | m4D_: done without optimization I assume? Anyhow; that code is generating two half-word loads; which if header is 2-byte aligned will work fine |
| 21:03.41 | roxfan | i guess it assumes that header is 4-byte aligned which makes header+10 2-byte aligned |
| 21:03.57 | m4D_ | davidc___: sure, without opts, debug-mode |
| 21:04.13 | m4D_ | now i'm terribly in need of disasm for gcc-binary |
| 21:04.16 | roxfan | i do wonder what's "mov r1, #0x45, 30", that doesn't look like a valid instruction |
| 21:04.24 | roxfan | m4D_: objdump -d |
| 21:04.44 | davidc___ | roxfan: yeah, I was wondering the same |
| 21:04.48 | roxfan | (arm-eabi-objdump or whatever is your prefix) |
| 21:05.27 | davidc___ | roxfan: I'm just assuming its a broken disasm or something |
| 21:07.03 | m4D_ | roxfan: how do i know the offset of the needed line to supply to objdump? i don't have gdb for wince |
| 21:07.33 | davidc___ | m4D_: just dump the whole file intermixed and grep? |
| 21:07.39 | roxfan | if you have debug info, try -d -S |
| 21:13.58 | m4D_ | ok, thanks -S - done the thing) here's disasm from gcc: http://pastebin.com/De4gbCah |
| 21:15.21 | davidc___ | m4D_: yeah, those are all whole-word loads/stores |
| 21:15.30 | davidc___ | m4D_: its an alignment problem |
| 21:15.55 | m4D_ | davidc___: is it possible to make gcc to produce emvc4-like code in such situations? |
| 21:16.47 | davidc___ | m4D_: not without fixing your code. |
| 21:16.59 | m4D_ | ooohh man, you're killing me |
| 21:17.00 | davidc___ | m4D_: though there is a way to get it to emit warnings |
| 21:17.27 | m4D_ | like -Wcast-alingn? |
| 21:17.36 | davidc___ | yeah, thats the one |
| 21:18.49 | m4D_ | ok, thanks for your help... i better start fixing this thing |
| 21:21.04 | davidc___ | m4D_: if you want my advice - especially if that code pattern is common: write a macro, that takes an array, and an offset to start from |
| 21:21.15 | davidc___ | and returns the value using the shift method that I wrote above |
| 21:22.44 | m4D_ | yeah, thanks, already on it)) the bigger problem is that's not the only common mistakes. there's also crashes in threads-stuff and it's going to be nightmare |
| 21:23.11 | davidc___ | m4D_: ah, heh. Can you run it on linux with valgrind? or is it tied to wince? |
| 21:24.07 | roxfan | davidc___: <roxfan> hm, apparently linux kernel provides get_unaligned() and put_unaligned() macros |
| 21:24.32 | davidc___ | ^^^ or grab the macros from there :P |
| 21:25.03 | m4D_ | davidc___: well, it uses some dma (rawfb) and i guess it's device-dependent |
| 21:25.21 | davidc___ | m4D_: ooh; sounds like you've got some real fun on your hands! |
| 21:25.37 | m4D_ | davidc___: yup) |
| 21:32.30 | *** join/#edev florian (~fuchs@82.113.121.35) |
| 21:32.30 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 22:01.28 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 22:22.16 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 22:44.36 | *** join/#edev andoo (~eric@p4FC5DDCD.dip.t-dialin.net) |
| 22:47.20 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |