--- Log for 26.03.117 Server: adams.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 20 days ago 00.01.04 Quit Moarc (Ping timeout: 240 seconds) 00.01.11 Quit paulk-collins (Read error: Connection reset by peer) 00.02.20 Join Moarc [0] (~chujko@a105.net128.okay.pl) 00.26.45 Join PurlingNayuki [0] (~Thunderbi@61.148.242.216) 00.31.11 Quit PurlingNayuki (Ping timeout: 260 seconds) 00.44.10 Quit Moarc (Ping timeout: 260 seconds) 00.47.27 Join Moarc [0] (~chujko@a105.net128.okay.pl) 01.00.12 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7066:fb00:910:63f9:9b66:a631) 01.14.16 Quit ZincAlloy (Quit: Leaving.) 01.22.06 *** Saving seen data "./dancer.seen" 01.22.31 Quit pamaury (Ping timeout: 260 seconds) 03.01.26 Quit MrZeus1 (Ping timeout: 240 seconds) 03.58.02 Join PurlingNayuki [0] (~Thunderbi@61.148.242.216) 04.02.24 Quit PurlingNayuki (Ping timeout: 260 seconds) 04.15.54 Quit duo8 (Ping timeout: 246 seconds) 04.22.07 *** Saving seen data "./dancer.seen" 04.29.24 Join PurlingNayuki [0] (~Thunderbi@61.148.242.216) 04.35.32 Quit PurlingNayuki (Ping timeout: 268 seconds) 04.37.10 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 05.00.50 Quit alexweissman (Remote host closed the connection) 05.21.16 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 05.37.34 Quit alexweissman (Read error: Connection reset by peer) 05.38.07 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 06.06.48 Quit robertd1 (Ping timeout: 268 seconds) 06.15.30 Quit alexweissman (Remote host closed the connection) 06.15.45 Join duo8 [0] (~ZNC-SRV-H@117.7.201.231) 06.22.10 *** Saving seen data "./dancer.seen" 06.32.17 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 06.36.31 Quit alexweissman (Remote host closed the connection) 06.38.01 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 06.49.20 Quit TheSeven (Disconnected by services) 06.49.28 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 07.27.58 Quit alexweissman (Remote host closed the connection) 07.34.47 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 07.38.49 Quit alexweissman (Remote host closed the connection) 08.22.11 *** Saving seen data "./dancer.seen" 08.49.24 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 08.53.47 Quit alexweissman (Ping timeout: 240 seconds) 09.23.39 Quit Jinx (Ping timeout: 240 seconds) 09.48.39 Join PurlingNayuki [0] (~Thunderbi@61.148.242.216) 10.22.15 *** Saving seen data "./dancer.seen" 10.32.35 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 10.40.42 Join petur [0] (~petur@rockbox/developer/petur) 10.49.45 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 11.10.13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.47.16 Join Guest24460 [0] (~gitterast@gsr198.internetdsl.tpnet.pl) 11.56.44 Quit Guest24460 (Quit: My laptop has gone to sleep. ZZZzzz�) 12.22.17 *** Saving seen data "./dancer.seen" 12.32.35 Quit PurlingNayuki (Ping timeout: 256 seconds) 13.11.01 Quit paulk-collins (Quit: Leaving) 13.11.20 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 13.53.45 Quit diox (Ping timeout: 264 seconds) 13.56.47 Quit rela (Ping timeout: 240 seconds) 13.57.11 Join diox [0] (~u@c80-216-194-28.bredband.comhem.se) 14.00.21 Join rela [0] (~x@pdpc/supporter/active/rela) 14.06.25 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7066:fb00:e4e3:80e5:2592:a214) 14.10.46 # pamaury: look like you have been much busy lately :) 14.14.52 # lebellium: yes, I have been away several times for work, I have had interviews for job and deadlines. 14.15.04 # And April will be similar 14.15.34 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 14.16.14 # pamaury: Do you have an idea how to trace why rb dies at startup on agptek? 14.16.53 # Leo told me that based on my suggestion they are working on a new Rocker with an "HD" screen :) 14.17.47 # wodz: does it die before main ? Did you try simpler programs than rockbox ? 14.17.54 # try with strace 14.19.25 # pamaury: It dies before main, yes. I tried simple programs and this works (and I can gdb them). 14.19.34 # pamaury: strace doesn't show up anything 14.21.45 # wodz: and it doesn't print any error message in the console? 14.21.50 # did you look in dmesg? 14.22.18 *** Saving seen data "./dancer.seen" 14.23.17 # pamaury: console says simply 'Killed.' 14.24.12 # pamaury: BTW the problem with setrlimit64/getrlimit64 is related with 'our' glibc compiled with large files support. 14.31.47 Quit michaelni (Ping timeout: 240 seconds) 14.32.57 # I don't see many possibilities for a kill before main(). Either a missing symbol (but I would expect an error message) or too much memory allocation in bss for example 14.35.58 # I was thinking about ulimit thing but I'd expect some error message to give a clue about exhausted resource 14.36.52 Quit alucryd (Remote host closed the connection) 14.37.58 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 14.38.27 # wodz: what is the size of the bss section ? I don't remember how memory is handled on hosted 14.39.26 # pamaury: according to readelf it is 211d844 which is enormous 14.41.37 # hum 14.41.49 # what is the memory size configured in configure ? 14.42.25 # memory=32 14.42.42 # how much memory does the device have ? 14.42.46 # 32 14.42.51 # then it's way to much 14.43.12 # the kernel takes several megabytes already, not even counting the other programs 14.43.14 # try with 16 14.44.36 # still 211d844 is waaaaay over 32MB 14.45.21 # isn't it like 33MB ? 14.45.24 # with memory=16 readelf reports 111d254 for bss 14.45.54 # hmm indeed 14.50.18 # Ha, now error is different 14.50.39 # /mnt/sd_0/rockbox: /usr/lib/libasound.so.2: no version information available (required by /mnt/sd_0/rockbox) 14.50.49 # pamaury: ^ 14.51.52 # weird 14.52.21 # give me a minute 14.52.33 Quit cc___ (Quit: WeeChat 1.6) 14.53.39 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 14.54.37 # hmm, looking at strace it looks like it dies on some mmap 14.54.38 # wodz: it's a bit unusual 14.54.50 # libasound on agptek doesn't have symbol versions 14.54.50 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 14.56.22 # maybe there is an option to disable symbol versioning, although I am not sure why one would do that 14.57.59 # wodz: apparently one can add --with-versioned=no to alsa-lib configure 14.59.08 # Is missing symbol versioning error or warrning? 14.59.10 # one annoying thing is that I don't know if an unversioned works on versioned. If not, that would mean we need two different alsa-lib versions 15.00.47 # wodz: I updated g#1570 15.00.49 # 3Gerrit review #1570 at http://gerrit.rockbox.org/r/1570 : 3Modernize toolchain script and add generic arm toolchain by Amaury Pouly 15.00.54 # I haven't tried it 15.01.45 # you don't have to rebuild everything 15.01.50 # pamaury: I reduced memory further to 8 and now I can run binary in gdb and get backtrace. http://paste.debian.net/924411/ 15.02.40 # wodz: ah so it's actually just a warning, good 15.03.00 # I know why it tries to throw panicf() at least 15.03.51 # ah? 15.05.30 # I was opening battery status file with O_RDWR, but this file is read only 15.06.05 # you will probably have to play with memory size to find a good value 15.06.16 # maybe 12 15.06.55 Join JanC_ [0] (~janc@lugwv/member/JanC) 15.07.47 # I'll stick with 8 for now as having ability to run in gdb is really useful 15.08.10 Quit JanC (Killed (karatkievich.freenode.net (Nickname regained by services))) 15.08.10 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 15.09.41 # Now it dies on switch_thread() 15.10.02 # but I have rockbox logo on screen! 15.10.14 # wodz: gdb might not like switch_thread 15.10.23 # good point 15.10.35 # because we use signals to switch threads I think 15.10.57 # without gdb rockbox segfaults as well 15.17.34 # I don't know much about threading 15.17.39 # maybe jhMikeS knows 15.17.51 Quit jhMikeS (Ping timeout: 258 seconds) 15.21.22 # he was apparently scared by the question :P 15.37.19 # pamaury: ok, I know what is direct cause of crash in switch_thread() BUT I have no clue why it is like that. thread->stack is NULL and hence stack overflow check makes NULL ptr dereference. http://paste.debian.net/924415/ 15.41.14 # I know nothing about the threading code, and it's quite complicated :-/ One possibility I see is that you are creating/using threads before the threading code is initialised? 15.43.47 # That was my thought as well. Need to step through main() to see what it calls actually 15.46.52 Quit preglow (Read error: Connection reset by peer) 15.47.08 Join preglow [0] (~thomj@2001:840:4243:3::101) 15.50.00 # pamaury: What sets stackbegin and stackend on hosted? 15.52.26 # wodz: I think it's set in ../firmware/target/hosted/samsungypr//system-.c: 15.52.41 # ../firmware/target/hosted/samsungypr/ypr1/system-ypr1.c for example 15.52.54 # I see. How does it actually work? 15.52.54 # it's supposed to be completely irrelevant for hosted 15.53.46 # pamaury: But __get_main_stack() does *stacksize = (uintptr_t)stackend - (uintptr_t)stackbegin; 15.54.21 # hmm, maybe stacksize can be 0 but actual pointer must be valid 15.54.23 # but is the result actually used on hosted? I know nothing about those. Just that some comments says it's not used I think 15.56.42 Quit petur (Quit: Leaving) 16.00.02 # now it crashes in some speex code 16.00.20 Quit zoktar (Ping timeout: 240 seconds) 16.00.40 Join Strife1989 [0] (~quassel@adsl-98-80-187-37.mcn.bellsouth.net) 16.02.29 Quit Strife89 (Ping timeout: 268 seconds) 16.02.39 Join zoktar [0] (~zoktar@78-72-39-137-no186.tbcn.telia.com) 16.02.39 Quit zoktar (Changing host) 16.02.40 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 16.07.18 Quit zoktar (Ping timeout: 258 seconds) 16.09.05 Join zoktar [0] (~zoktar@78-72-39-137-no186.tbcn.telia.com) 16.09.05 Quit zoktar (Changing host) 16.09.05 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 16.19.33 Join PurlingNayuki [0] (~Thunderbi@61.148.242.216) 16.22.21 *** Saving seen data "./dancer.seen" 16.23.00 Part Asara 16.30.18 # pamaury: After commenting out HAVE_TAGCACHE so tagcache_init() is skipped I have crash in lcd_alpha_bitmap_part_mix() which looks like some memory corruption so something is fundamentally broken 16.45.34 Join ender [0] (krneki@foo.eternallybored.org) 16.48.12 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 16.48.21 Quit MrZeus1 (Ping timeout: 264 seconds) 16.56.08 Quit PurlingNayuki (Ping timeout: 264 seconds) 17.05.58 # wodz: I don't know, it works like a charm on nwz... 17.10.25 # th only obvious difference is arm vs mips 17.11.07 Quit wodz (Ping timeout: 240 seconds) 17.17.14 # tfw x1000 going faster than jz 17.17.40 Quit zoktar (Ping timeout: 240 seconds) 17.18.10 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-46-53-165-217.telecom.by) 17.18.16 Join zoktar [0] (~zoktar@78-72-39-137-no186.tbcn.telia.com) 17.18.16 Quit zoktar (Changing host) 17.18.16 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 17.29.47 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 17.47.42 # pamaury: In order to exclude 32bit lcd driver issue, I set it up as 24bit driver (knowing lcd will be garbage) but rb still crashes. It crashes on dereferencing pointer which is crap (like NULL or 0x1) in speex code but I think the corruption must be much earlier and speex just happen to trigger that 17.51.10 # wodz: if the corruption is visible with 32bit lcd, that means it happens early on boot, you should investigate with this, take a pointer that becomes corrupted and narrow down the last places where is was still ok and then bad 17.52.27 # pamaury: with 32bit driver rockbox logo is displayed correctly and then it goes mad somewhere in tagcache_init() afaik 17.56.34 # pamaury: I don't really understand the thing with stackbegin and stackend. IMO it works purely by luck. If you define stackbegin to some variable allocated on the stack in system_init() it becomes invalid just after returning from this function. 18.00.32 # wodz: my understanding is that stackbegin and stackend are only used to get the stack size on native 18.00.51 # and then check for stack overflow I guess 18.01.05 # I just copied the code from other hosted targets 18.01.10 # pamaury: yes, stackoverflow is checked on hosted as well. 18.01.35 # pamaury: I know but IMO this is simply wrong 18.01.48 # and misleading 18.02.22 # wodz: hosted doesn't check for stack overflow on main thread because if you set stackbegin=stackend, then stacksize=0 and the stkov code ignores 0 size stacks 18.02.36 # on hosted you cannot get the pointer and size of the main stack anyway 18.03.03 # though I agree that the proper approach would be to handle this in thread.c and not in every target 18.04.26 # I might be wrong of course, I don't understand much of thread.c 18.04.46 # but since all hosted targets do that and all work except x1000, I assume that the problem is not there 18.04.50 # gdb disagrees with you. In switch_thread() there is line if (UNLIKELY(thread->stack[0] != DEADBEEF) && thread->stack_size > 0) which means that thread->stack[0] will be checked even when thread->stack_size == 0 18.06.12 # I agree that problem is elsewhere but It took me fair bit of time to understand why it crashed in switch_thread() 18.06.32 # ah you are right, this condition seems like a stupid overlook, you should exchange the two conditions order 18.06.42 # yep 18.07.05 # it's a bit strange though 18.07.23 # because on nwz, it returns an address which is on the stack, so this address will always be valid 18.07.34 # (even if it's content is garbage) 18.09.32 # it is valid in the sense it is on the stack but don't you think this is stupid to return pointer to random stack part and check if this is not DEADBEEF? 18.09.41 Join ZincAlloy [0] (~Adium@p57A72E5A.dip0.t-ipconnect.de) 18.09.52 # wodz: I think the check in thread.c is stupid 18.10.12 # it's the classic if(array[0] == .... && array_size > 0) 18.10.23 # ie checking content before checking size 18.12.44 # but actually, it seems to me now that we should just set stackbegin = stackend = 0 in this case 18.12.57 # since it's supposed to be useless 18.22.25 *** Saving seen data "./dancer.seen" 18.26.01 # * __builtin gets Ballerburg up and running on SDL 18.27.32 # <__builtin> the big issue is that everything is hardcoded for 640x480 screen res 18.28.09 # <__builtin> so for now I can only see 25% of the screen :D 18.37.53 # You are insane with multiplying number of plugins. You should be responsible for defining keymaps for plugins on each new port :P 18.38.43 # <__builtin> I feel the ad-hoc keymaps need to be centralized 18.39.12 # __builtin: feel free to propose something 18.39.58 # <__builtin> PLA is great and all for simple stuff, but when it gets more involved (i.e. simultaneous presses), keymaps are the only way to go 18.41.02 # I know. I know also that defining all keymaps for new port is nightmare 18.41.12 # <__builtin> I think there's a lot of duplication of essentially the same keymap between plugins though 18.41.35 # <__builtin> i.e. 4 directions + action + menu 18.42.32 # + quit 18.42.59 # <__builtin> it would make life easier for everyone to have these definitions in a centralized header somewhere 18.48.45 # <__builtin> this probably wouldn't replace PLA, but instead provide a more flexible version of it 18.50.25 # __builtin: BTW maybe you are interested in finishing g#1389 ? I think working tts will be highly appreciated feature. 18.50.27 # 3Gerrit review #1389 at http://gerrit.rockbox.org/r/1389 : 3Port of picoTTS by Marcin Bukat 18.53.43 # <__builtin> I'll take a look 18.54.57 # __builtin: tts engine basically works, audio glue code is f*** up. I had simpler version which worked but I lost it somehow. The code is borrowed from mpgplayer actually. 18.56.26 # __builtin: I'm all for simplifying keymaps for plugins, but if you do, please please please, look at all targets before doing that. Some of them have crazy keys so we need a flexible system 18.56.39 # also some plugins have ways to many keys required, that's a nightmare 18.57.56 # <__builtin> I'll probably just leave those that require a bunch of keys alone for the time being 18.58.34 # IMO the most desired functionality would be per plugin enable for each target. So you could define keymap and enable plugin one by one and not all or nothing 18.59.23 # <__builtin> and they would be enabled in the target header? 18.59.36 # <__builtin> such as PLUGIN_ENABLE_DOOM 18.59.38 # <__builtin> ? 19.01.33 # no please not the target header, and possibly not new defines 19.01.51 # I don't know how to do it cleanly 19.02.05 # I don't know how to do it cleanly but it has to be clean 19.02.47 # I would actually suggest to come up with a header that somehow lists plugins to NOT compile 19.03.43 # because the goal at the end of the day is to compile everything, you only want to do work if you want to disable something imo 19.14.45 # pamaury: It looks like threading code for mips doesn't work as it should on hosted 19.18.19 # not sure what you mean 19.19.16 # pamaury: the corruption happens on load_context() in rockbox/firmware/asm/mips/thread-mips32.c 19.21.29 # wodz: I'm a bit confused, I thought on hosted it's not using this code 19.21.51 # it's supposed to use thread-unix.c 19.22.08 # That would explain a lot. 19.22.25 # There is some magic define needed somewhere 19.22.47 # wodz: probably asm.make 19.23.36 # pamaury: I don't see anything hosted specific there 19.23.42 # let me see 19.25.18 # wodz: it's a simple fix actually 19.25.21 # HAVE_SIGALTSTACK_THREADS should be defined somewhere 19.25.24 # look at firmware/asm/arm/thread.h 19.25.31 # it takes into account hosted 19.25.38 # the asm/mips/thread.h does not 19.25.46 # I think 19.26.14 # hum, I may have spoken too quickly 19.26.14 # it only include nothing more. It is needed on hosted 19.26.41 # so thread.c -> thread-internal.h -> asm/thread.h 19.27.12 # and thread.c -> asm/thread.c 19.27.48 # and asm/thread.c uses thread-unix.c if HAVE_SIGALTSTACK_THREADS is defined 19.28.07 # but I can't find where HAVE_SIGALTSTACK_THREADS is defined, maybe in configure 19.28.10 # aaaah, it should be defined in tools/configure 19.30.30 # I don't really understand in configure though 19.32.23 # wodz: actually on the nwz port, autoconfig.h defines ASSEMBLER_THREADS 19.32.42 # and the ypr0 code doesn't seem to do anything special 19.33.33 # so, either 1) the arm code somehow works on both native and hosted, but not the mips one, or 2) it's an overlook and it works on arm purely by chance 19.33.50 # autoconfig.h? I don't have such file here (in build dir) 19.34.17 # autoconf.h 19.34.23 # that's the file generated by configure 19.34.37 # ah, no I have it 19.34.56 # #define ASSEMBLER_THREADS 19.35.23 # so it looks like on arm it is working on hosted as well 19.35.41 # I am wondering how threading worked on android mips 19.35.43 # it might be that the mips code is making some assumption not true on hosted 19.35.57 # gevaerts: ping 19.36.48 # * gevaerts fears a question he doesn 19.36.51 # * pamaury is looking at thread-mips32.c but fails to understand the code 19.36.55 # t know the answer to! 19.37.55 # gevaerts: the question is how autoconf.h looks like on android mips. Which threading model is used? 19.38.20 Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) 19.38.32 # I don't have Android SDK and NDK installed to check 19.38.48 # #define HAVE_SIGALTSTACK_THREADS 19.39.05 # aha 19.39.21 # maybe we should understand why the assembler thread code is not working on hosted ? 19.39.34 # (whereas it does for arm) 19.40.17 # pamaury: I guess we under store registers since rockbox native assumes cooperative threading so it might not save some registers 19.41.00 # that's also the case on arm 19.41.16 # we do cooperative threading on hosted arm 19.44.00 # looks like it is not storing s8 register 19.44.34 # s8? 19.44.36 # hmm, maybe not, s8 is aliased as fp 19.44.37 # you mean fp 19.45.06 # according to this: https://www.student.cs.uwaterloo.ca/~cs350/W11/notes/threads.pdf the store part is correct 19.46.53 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7066:fb00:555d:2828:5e03:593e) 19.48.29 # I am a bit confused about start_thread 19.49.13 # I don't understand why it loads from $8 and $9 19.49.36 # ah ok because of load_context 19.52.02 # I set breakepoint in load_context() and start param points in the middle of sb_decode() while it is supposed to be "scroll" thread. something is really fishy 20.01.25 # wodz: you mean context->start is completely wrong ? 20.05.23 # yes 20.06.07 # wodz: what about the context pointer itself ? 20.06.30 # looks valid 20.07.23 # wodz: what is value of context->r[0] and context->r[1] ? 20.16.34 # context->r[0] = 0xe2712c, context->r[1] = 0x4a9ea8 20.16.52 # wodz: r[0] should be a pointer to the context itself 20.16.59 # and r[1] to the main thread function 20.17.09 # at least on thread startup 20.17.29 # (struct thread_entry *) 0xe2712c <__thread_entries+156> 20.17.43 # so context->r[0] indeed points to self 20.17.54 # yeah, good. And r[1] ? 20.18.06 # and context->start 20.18.18 # yeah, it points to scroll_thread() 20.18.43 # context->start is bogus 20.19.03 # wodz: can you dump the code of the function start_thread() ? 20.19.15 # and _start_thread() 20.19.24 # the code is a bit weird, it seems to be a huge hack 20.19.34 # you mean objdump rockbox.elf? 20.20.19 # yeah 20.20.27 # http://paste.debian.net/924462/ 20.20.40 # I don't understand why the code doesn't simply put naked attribute 20.21.13 # ok looks correct 20.21.24 # so context->start doesn't point to 004b959c ? 20.21.55 # Maybe naked was broken at that time. 20.22.04 # no, context->start = 0x4c0000 20.22.26 # wodz: can you try to rename _start_thread to start_thread, add naked attribute 20.22.30 *** No seen item changed, no save performed. 20.22.32 # ie like asm/arm/thread.c 20.23.56 # sure, its just I need to get kids to bed so it will take some time 20.25.46 Quit MrZeus1 (Ping timeout: 240 seconds) 20.27.31 # pamaury: warning: ‘naked’ attribute directive ignored 20.27.41 # pamaury: So I guess thats the answer 20.28.45 # interesting 20.29.34 # and what does 0x4c0000 correspond to ? (in rockbox.map) 20.31.30 # pamaury: it is in the middle of some speex function 20.32.05 # looks like the bottom 16 bits are missing, since this is MIPS I'd suspect there's a missing ori/addi following a lui heh 20.32.33 # pretty possible 20.32.33 # wodz: maybe the compiler emits the wrong type of relocation for some reason 20.33.12 # wodz: mybe you could try to put this start_thread function in .S file with proper .global start_thread and all 20.33.24 # bingo! Can't find matching LO16 reloc against `.text' for R_MIPS_GOT16 at 0x132c in section `.text' 20.33.50 # wodz: maybe try to add .global start_thread in the asm block ? 20.34.02 # * pamaury thinks defining this function in C code is a hack 20.39.35 # nop, that doesn't work. IMO this should be moved to .S as it is pure asm anyway 20.40.43 # agreed 20.41.00 # wodz: alternatively, you could turn start_thread into a proper function 20.41.10 # and make load_context load the context into a0 20.41.19 # that too 20.41.39 # actually why it doesn't follow calling convention actually? 20.42.06 # no idea, seems a bit unatural 20.43.42 # wodz: something like this https://gist.github.com/pamaury/48e17fbd5ee7c1078d1eea80e5d98c2d ? 20.48.55 # crashes in switch_thread() 20.49.34 # maybe I got the code wrong 20.49.45 # is the address in context->start correct now ? 20.50.58 # let me see 20.55.01 # yes, context->r[0], context->r[1] and context->start seems valid 20.56.35 # hmm, ra is 0 20.56.36 # I must have screwed up something 20.57.35 # wodz: can you objdump start_thread ? 20.58.14 # http://paste.debian.net/924467 20.59.46 # this code is crazy stupid 20.59.56 # it compiled with -O0 21.01.38 # I don't see what is wrong 21.01.46 # you might have to single step from load_context to catch the problem 21.09.22 Quit wodz (Ping timeout: 258 seconds) 21.10.46 Quit ZincAlloy (Quit: Leaving.) 21.12.14 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 21.18.52 # pamaury: After full recompile it seems to be working (i.e I get proper panicf() from my code) 21.21.26 Join ZincAlloy [0] (~Adium@p57A72E5A.dip0.t-ipconnect.de) 21.21.35 # wodz: with old code or new code ? 21.59.36 # with your patch in start_thread 22.17.15 Join webguest194 [0] (~5d41e969@www.haxx.se) 22.20.46 Quit wodz (Ping timeout: 256 seconds) 22.22.10 Quit webguest194 (Quit: CGI:IRC (Ping timeout)) 22.22.34 *** Saving seen data "./dancer.seen" 22.23.54 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 22.27.22 # * wodz \o/ main menu reached 22.28.20 # :) 22.36.43 # wodz: great :) 22.37.09 # pamaury: now I get crash when entering 'Files' from main menu :P 22.40.13 # where is the crash ? 22.42.10 # pamaury: http://paste.debian.net/924492 22.42.54 # but this is strange since the offending line is dptr->attr = info.attribute and in gdb I can do set dptr->attr = info.attribute just fine 22.45.23 # <__builtin> any german speakers here? 22.45.43 Quit preglow (Ping timeout: 252 seconds) 22.47.22 # * [Saint] summons pixelma 22.47.40 # <__builtin> mmh, google translate barely works 22.48.07 # <[Saint]> Yeah, Google translate for non-germanic language -> germanic language is hilarious. 22.48.18 # <[Saint]> For bonus points, translate it back and forth a few times. 22.48.29 # <[Saint]> It usually becomes garbage. 22.48.54 # [Saint]: you could try this trick with slavic language too :P 22.55.55 DEBUG EOF from server (Connection reset by peer) (snapshot: netstuff.c line 545) 22.55.55 *** Cleanup 22.55.55 *** Cleanup 22.55.55 *** Saving seen data "./dancer.seen" 22.55.55 *** Exit 22.55.57 *** Started Dancer V4.16 22.55.57 *** Connected to irc.freenode.net on port 6667 22.55.57 *** Logfile for #rockbox started 22.55.57 Mode "logbot :+i" by logbot 22.56.04 *** Server message 501: 'logbot :Unknown MODE flag' 22.56.04 Join logbot [0] (~rockbox@giant.haxx.se) 22.56.04 Join aevin [0] (eivindsy@unaffiliated/aevin) 22.56.04 Join froggyman [0] (~frogs@unaffiliated/froggyman) 22.56.04 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 22.56.04 Join ZincAlloy [0] (~Adium@p57A72E5A.dip0.t-ipconnect.de) 22.56.04 Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) 22.56.04 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 22.56.04 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-46-53-165-217.telecom.by) 22.56.04 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 22.56.04 Join ender [0] (krneki@foo.eternallybored.org) 22.56.04 Join Strife1989 [0] (~quassel@adsl-98-80-187-37.mcn.bellsouth.net) 22.56.04 Join JanC [0] (~janc@lugwv/member/JanC) 22.56.04 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 22.56.04 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 22.56.04 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 22.56.04 Join rela [0] (~x@pdpc/supporter/active/rela) 22.56.04 Join diox [0] (~u@c80-216-194-28.bredband.comhem.se) 22.56.04 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 22.56.04 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 22.56.04 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 22.56.04 Join duo8 [0] (~ZNC-SRV-H@117.7.201.231) 22.56.04 Join Moarc [0] (~chujko@a105.net128.okay.pl) 22.56.04 Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) 22.56.04 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 22.56.04 Join fs-bluebot [0] (~fs-bluebo@xd9baf2b7.dyn.telefonica.de) 22.56.04 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.56.04 Join dys [0] (~dys@109.40.0.59) 22.56.04 Join ender` [0] (krneki@2a01:260:4094:1:42:42:42:42) 22.56.04 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 22.56.04 Join zoid [0] (~zoid@unaffiliated/taxationistheft) 22.56.04 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 22.56.04 Join [Saint] [0] (~sinner@rockbox/staff/saint) 22.56.04 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 22.56.04 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 22.56.04 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 22.56.04 Join prg318 [0] (~prg318@deadcodersociety/prg318) 22.56.04 Join idonob [0] (~Owner@S010600259c3e7d7b.vs.shawcable.net) 22.56.04 Join Jack87 [0] (~Jack87@nasadmin/admin/jack87) 22.56.04 Join Petri152 [0] (~Petri@petritrebs.ca) 22.56.04 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 22.56.04 Join puckipedia [0] (puck@puckipedia.com) 22.56.04 Join vifino- [0] (~vifino@tty.sh) 22.56.04 Join utrack_ [0] (~utrack@21422.s.t4vps.eu) 22.56.04 Join funman [0] (~fun@rockbox/developer/funman) 22.56.04 Join munch [0] (pls@gateway/shell/elitebnc/x-elfucwuiphdaphfn) 22.56.04 Join x56 [0] (~0x56@unaffiliated/x56) 22.56.04 Join Horrorcat [0] (129994c4c6@unaffiliated/horrorcat) 22.56.04 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 22.56.04 Join quaz0r [0] (quaz@c-67-183-243-24.hsd1.wa.comcast.net) 22.56.04 Join Amboyna [0] (~TorC@fsf/member/TorC) 22.56.04 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.56.04 Join rasher [0] (~rasher@rockbox/developer/rasher) 22.56.04 Join foolsh [0] (~starchase@162-204-199-234.lightspeed.sbndin.sbcglobal.net) 22.56.04 Join St0neHead [0] (stonehead@2a01:7e00:e001:3700:6667::2) 22.56.04 Join mercutio [0] (ben@pearl.meh.net.nz) 22.56.04 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 22.56.04 Join madk [0] (~noneofyou@107.170.140.154) 22.56.04 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 22.56.04 Join akaWolf [0] (~akaWolf@akawolf.org) 22.56.04 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-dxgqqpstcysrghut) 22.56.04 Join MrZeus [0] (~MrZeus@81.144.218.162) 22.56.04 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 22.56.04 Join Sockbat [0] (sockbat@gateway/shell/fnordserver.eu/x-zieimjmizsfjlhat) 22.56.04 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 22.56.04 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 22.56.04 Join user890104 [0] (Venci@unaffiliated/user890104) 22.56.04 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 22.56.04 Join prof_wolfff [0] (~prof_wolf@62.83.49.172.dyn.user.ono.com) 22.56.04 Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) 22.56.04 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 22.56.04 Join shmibs [0] (~shmibs@shmibbles.me) 22.56.04 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 22.56.04 Join scorche [0] (~scorche@rockbox/administrator/scorche) 22.56.04 Join tomflint [0] (~tomflint@unaffiliated/tomflint) 22.56.04 Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) 22.56.04 Join neutric [0] (~ah@unaffiliated/neutric) 22.56.04 Join hiro [0] (~hiro@2001:41d0:8:e46:5054:ff:feac:f713) 22.56.04 Join naraic [0] (naraic@spoon.netsoc.tcd.ie) 22.56.04 Join bzed [0] (~bzed@shell.bzed.at) 22.56.04 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 22.56.04 Join @ChanServ [0] (ChanServ@services.) 22.56.04 Join CustosL1men [0] (~CustosLim@unaffiliated/cust0slim3n) 22.56.04 Join knittl [0] (~knittl@unaffiliated/knittl) 22.56.04 Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux) 22.56.04 Join andrewthecoder [0] (~beveradb@irc.beveridge.uk) 22.56.04 Join zu [0] (~zu@ks387228.kimsufi.com) 22.56.04 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 22.56.04 Join jvoisin [0] (~jvoisin@dustri.org) 22.56.04 Join cttttt [0] (sid135570@gateway/web/irccloud.com/x-inevvxllsjjeegeo) 22.56.04 Join Cu5tosLimen [0] (~CustosLim@unaffiliated/cust0slim3n) 22.56.04 Join anonus [0] (~anonymous@citadel.niflheim.info) 22.56.04 Join APLU [0] (~mulx@eva.aplu.fr) 22.56.04 Join ved [0] (ved@ddsbox.tk) 22.56.04 Join maraz [0] (maraz@kapsi.fi) 22.56.04 Join shrizza_ [0] (~shrizza@oki-dc-urasoe01-187.glbb.ne.jp) 22.56.04 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 22.56.04 Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) 22.56.04 Join vflyson [0] (~vflyson@cupcake.uberspace.net) 22.56.04 Join rudi_s [0] (~simon@kraftwerk.ruderich.eu) 22.56.04 Join yosafbridge [0] (~yosafbrid@68.ip-149-56-14.net) 22.56.04 Join alexbobp [0] (~alex@testificate.xen.prgmr.com) 22.56.04 Join gluytium [0] (U2FsdGVkX1@ma.sdf.org) 22.56.04 Join __builtin [0] (~xray@rockbox/developer/builtin) 22.56.04 Join Elfish [0] (amba@84.201.30.174) 22.56.04 Join uwe_android [0] (~uwe_andro@static.173.76.9.176.clients.your-server.de) 22.56.04 Join uwe_ [0] (~uwe_@dslb-084-056-050-120.084.056.pools.vodafone-ip.de) 22.56.04 Join mikroflops [0] (~yogurt@178.174.137.46) 22.56.04 Join ranmachan [0] (~ranma@yumi.uguu.de) 22.56.04 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 22.56.04 Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh) 22.56.04 Join fIorz [0] (nobody@rain.florz.de) 22.56.04 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 22.56.04 Join dongs [0] (~dongs@bcas.tv) 22.56.04 Join CommunistWitchDr [0] (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) 22.56.04 Join marex-cloud [0] (sid137234@gateway/web/irccloud.com/x-wkxgsoyjpzyvcvzf) 22.56.04 Join ps-auxw [0] (~arneb@p578F7FEC.dip0.t-ipconnect.de) 22.56.04 Join Marex [0] (~Marex@195.140.253.167) 22.56.04 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 22.56.04 Join atsampso1 [0] (~ats@cartman.offog.org) 22.56.04 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 22.56.04 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 22.56.04 Join snw [0] (~snow_bcks@ganon.dot-server.net) 22.56.04 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri) 22.56.35 # <__builtin> what does "Durchführen eines Zuges" mean when in the context of code? 22.58.00 # <[Saint]> something a train? 22.58.10 # <[Saint]> oops, thought this was *-community 22.59.07 # unlikely. more like "performing a move" in case the code is from a game :-) 23.00.40 Join webguest46 [0] (~5d41e969@www.haxx.se) 23.02.19 Quit ZincAlloy (Quit: Leaving.) 23.03.25 # <[Saint]> piece-meal translate of the subset of words I know in German foils me again. 23.03.40 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7066:fb00:f911:2965:566b:456a) 23.05.38 Quit webguest46 (Quit: CGI:IRC (Ping timeout)) 23.19.28 Join arandomone [0] (~Creator@176-12-25-113.pon.spectrumnet.bg) 23.21.21 Quit wodz (Quit: Leaving) 23.27.52 Join Jinx [0] (Dojo@unaffiliated/jinx) 23.35.25 Join jhMikeS [0] (~jethead71@24.192.177.173) 23.35.50 Quit paulk-collins (Quit: Leaving) 23.41.32 Join roxfan [0] (~roxfan@43.234-245-81.adsl-dyn.isp.belgacom.be) 23.51.26 Join krabador [0] (~krabador@unaffiliated/krabador) 23.52.27 Join preglow [0] (~thomj@2001:840:4243:3::101) 23.58.36 Quit pamaury (Ping timeout: 240 seconds)