**** BEGIN LOGGING AT Sun Feb 19 02:59:58 2012
Feb 19 09:32:33 <GarthPS> JaMa: hello. do you have some news about eglibc not building ?
Feb 19 10:36:33 <morphis> heyho
Feb 19 13:49:42 <DocScrutinizer> mickeyl: when did you last time update specs from wirelessmodemapi.com?
Feb 19 14:19:47 <GNUtoo-desktop> hi mrmoku 
Feb 19 14:20:19 * GNUtoo-desktop opkg upgrades mrmoku so he can work on gta04
Feb 19 14:20:51 <GNUtoo-desktop> mrmoku, in other words, is the build finished etc...
Feb 19 14:25:13 <mrmoku> DocScrutinizer: wirelessmodemapi is no more since long I think
Feb 19 14:25:25 <mrmoku> GNUtoo-desktop: no, not yet
Feb 19 14:25:30 <GNUtoo-desktop> ok
Feb 19 14:26:07 <DocScrutinizer> mrmoku: well, it's down, that's for sure
Feb 19 14:26:19 <DocScrutinizer> but still "existing"
Feb 19 14:27:13 <DocScrutinizer> mrmoku: that's why I ask what's the most recent version of the docs we pulled from there
Feb 19 14:27:45 <DocScrutinizer> I'm not sure I'm "up to date" - whatever that means in this context
Feb 19 14:28:35 <DocScrutinizer> I also wonder what's the story with ofono and mer and meego now. AIUI ofono mainly driven by intel, no?
Feb 19 14:29:22 <DocScrutinizer> and meego-real/mer based on ofono
Feb 19 14:29:30 <mrmoku> yeah, I think so
Feb 19 14:29:43 <mrmoku> (regarding Intel)
Feb 19 14:29:54 <DocScrutinizer> and ofono kinda fsckd without wirelessmodemapi
Feb 19 14:30:34 <DocScrutinizer> so what's the deal with Nokia promising to support mer, while they actively nuke ofono?
Feb 19 14:31:36 <DocScrutinizer> Nokia way more rogue than they always claimed to be (not)
Feb 19 14:33:35 <DocScrutinizer> what's the minimum duration for support like wiki, websites in general, download of firmware etc, that a customer may legally expect and demand from a company like Nokia for their products like N900/N9 ?
Feb 19 14:34:36 <DocScrutinizer> I'd tend to argue that wirelessmodemapi.com is part of such support for N900 and N9
Feb 19 14:36:06 <mrmoku> nokia most probably would disagree ;)
Feb 19 14:36:16 <DocScrutinizer> it's been there when I bought the device, it's an immuatable part of direct support for the device, and maybe I never had bought the product if that support wasn't available at the time of purchase and reasonably expectable for another number of years
Feb 19 14:37:13 <DocScrutinizer> but hey, they don't even *repair* devices anymore, after just a tad more than 2 years :-/
Feb 19 14:37:22 <DocScrutinizer> I bet that's not legal
Feb 19 14:39:46 <mrmoku> I fear it is legal
Feb 19 14:40:13 <DocScrutinizer> there've been cases at court where it's been decided that maufacturers are supposed to provide spare parts for a raher clearly defined number of years minimum, depending on class of device etc, and I bet 2 years was not such a minimum allowable timespan for any device/good except maybe clothes and their buttons
Feb 19 14:41:19 <mrmoku> ok :)
Feb 19 14:41:31 <DocScrutinizer> nota bene this timespan *starts* to run when device is no longer sold
Feb 19 14:41:48 <GNUtoo-desktop> I think apple got condamned by the justice for that in italy( for providing less than 2 years)
Feb 19 14:41:54 <DocScrutinizer> NOT when device is sold first time
Feb 19 14:49:30 <DocScrutinizer> made up case: I run a truckage, and got all my drivers/trucks a N900 with a custom proprietary software for tracking/sheduling/whatnot. I thus bought 150 N900 8 months ago, and now that MyTruckageManager rev0.99 is about to enter rev1.0 state and everything finally seems to work after some dozen kBucks paid to the sw-house writing that app for me, I have to learn Nokia doesn't sell N900 anymore, they don't offer any really 
Feb 19 14:49:31 <DocScrutinizer> compatible successor product, and they even don't offer repair for the devices I bought
Feb 19 14:51:04 <DocScrutinizer> WTF?
Feb 19 14:53:42 <DocScrutinizer> I think the basic legal rule is: a device counts as discontinued no sooner than either a) the company explicitly announced discontinuation, or b) a valid successor device gets marketed by same company. 
Feb 19 14:53:57 <DocScrutinizer> you could argue for N900 neither of both happened
Feb 19 14:54:54 <DocScrutinizer> only then the timespan for support they have to provide *starts* to run
Feb 19 14:55:53 <DocScrutinizer> and that timespan is for sure no less than 2 years, as even "gewaehrleistung" in EU is 24 months
Feb 19 15:48:07 <DocScrutinizer> (wirelessmodemapi.com)
Feb 19 15:48:09 <DocScrutinizer> [2012-02-19 16:43:16] <DocScrutinizer> down doesn't reassure me of Nokia's willingness to support FOSS development for their modems
Feb 19 15:48:10 <DocScrutinizer> [2012-02-19 16:43:24] <Stskeeps> keep in mind the modem division got sold to Renesas
Feb 19 15:52:15 <pespin> tablet sold with gnu/linux -> http://makeplaylive.com/
Feb 19 17:43:16 <GNUtoo|laptop> JaMa, hi
Feb 19 17:43:26 <GNUtoo|laptop> JaMa, how do you find the obtimal jffs2 values?
Feb 19 17:44:00 <GNUtoo|laptop> like ERASEBLOCKSIZE = "0x20000"
Feb 19 17:44:05 <GNUtoo|laptop> I want to add it for gta04
Feb 19 17:44:14 <GNUtoo|laptop> values for om-gta02 work
Feb 19 17:44:20 <GNUtoo|laptop> but I've no idea if it's obtimal or not
Feb 19 17:52:28 <GNUtoo|laptop> ok it's in /proc/mtd
Feb 19 18:25:19 <GNUtoo|laptop> JaMa, hi
Feb 19 18:25:24 <GNUtoo|laptop> JaMa, I've that:
Feb 19 18:25:26 <GNUtoo|laptop> DEBUG: while parsing do_rootfs, unable to handle non-literal command '${IMAGE_PREPROCESS_COMMAND}'
Feb 19 18:33:49 <GNUtoo|laptop> mrmoku, did you have that ^^^
Feb 19 19:12:19 <JaMa> GNUtoo|laptop: never seen this where it's used and is it defined for other machines/images?
Feb 19 19:17:38 <mrmoku> GNUtoo|laptop: running task 1760
Feb 19 19:17:40 <GNUtoo|laptop> it's only +=
Feb 19 19:17:45 <mrmoku> so... dunno yet
Feb 19 19:17:47 <GNUtoo|laptop> ok
Feb 19 19:17:51 <GNUtoo|laptop> it's at parsing
Feb 19 19:17:55 <GNUtoo|laptop> so you don't have it
Feb 19 19:17:57 <mrmoku> ahh, ok
Feb 19 19:18:02 <mrmoku> yeah, then I don't have it
Feb 19 19:18:10 <mrmoku> with a freshly cloned shr-chroot
Feb 19 19:37:10 <GNUtoo|laptop> JaMa, basically grep gives that:
Feb 19 19:37:30 <GNUtoo|laptop> openembedded-core/meta/classes/image.bbclass:	${IMAGE_PREPROCESS_COMMAND}
Feb 19 19:37:38 <GNUtoo|laptop> and 2 "definitions" :
Feb 19 19:37:50 <GNUtoo|laptop> openembedded-core/meta/classes/image-mklibs.bbclass:IMAGE_PREPROCESS_COMMAND += "mklibs_optimize_image; "
Feb 19 19:37:50 <GNUtoo|laptop> openembedded-core/meta/classes/image-prelink.bbclass:IMAGE_PREPROCESS_COMMAND += "prelink_image; "
Feb 19 19:37:54 <GNUtoo|laptop> but that's all
Feb 19 19:38:41 <JaMa> what's the I in that image.bbclass?
Feb 19 19:39:39 <GNUtoo|laptop> what do you mean by 'I'
Feb 19 19:39:40 <GNUtoo|laptop> ?
Feb 19 19:40:06 <GNUtoo|laptop> I tried to add jffs2 images in machine config (gta04.conf)
Feb 19 19:40:14 <GNUtoo|laptop> but when I remove it
Feb 19 19:40:21 <GNUtoo|laptop> it still does the error
Feb 19 19:40:35 <GNUtoo|laptop> so maybe it got cached somehow?
Feb 19 19:40:42 <GNUtoo|laptop> I removed bb_codeparser*
Feb 19 19:40:44 <GNUtoo|laptop> but still
Feb 19 19:43:03 <GNUtoo|laptop> JaMa, ^^^
Feb 19 19:51:45 <JaMa> 20:37:30 < GNUtoo|laptop> openembedded-core/meta/classes/image.bbclass:I${IMAGE_PREPROCESS_COMMAND}
Feb 19 19:52:08 <JaMa> there is some 'I' before it at least how I see it in your paste
Feb 19 19:52:15 <JaMa> maybe it's just tab
Feb 19 19:52:45 <GNUtoo|laptop> it's tab
Feb 19 19:52:56 <GNUtoo|laptop> I don't see the I
Feb 19 19:53:44 <GNUtoo|laptop> and all other lines before have tab too
Feb 19 19:53:57 <GNUtoo|laptop> ( in fakeroot do_rootfs () )
Feb 19 19:57:10 <JaMa> and is it the same for all machines or just om-gta04?
Feb 19 19:57:18 <GNUtoo|laptop> I'll look
Feb 19 19:57:37 <GNUtoo|laptop> same for all machines
Feb 19 19:58:32 <JaMa> what bitbake version do you have?
Feb 19 19:59:11 <GNUtoo|laptop> adc041fd9e3def29cdf9c1ae4849c5383bac46e5
Feb 19 19:59:16 <GNUtoo|laptop> so lastest
Feb 19 19:59:30 <GNUtoo|laptop> (lastest from master branch)
Feb 19 19:59:40 <GNUtoo|laptop> let me look in bitbake git reflog
Feb 19 20:01:18 <JaMa> shr-chroot has almost the same :/
Feb 19 20:01:27 <JaMa> will try to upgrade it in chroot after image build
Feb 19 20:02:10 <GNUtoo|laptop> going back with bitbake at tag 1.15.1 seem to trigger a progress bar
Feb 19 20:03:16 <GNUtoo|laptop> ahhh
Feb 19 20:03:19 <GNUtoo|laptop> sorry
Feb 19 20:03:27 <GNUtoo|laptop> I picked the wrong error
Feb 19 20:03:33 <GNUtoo|laptop> ERROR: Could not include required file linux_2.6.34.bb######################################  | ETA:  00:00:01
Feb 19 20:03:39 <GNUtoo|laptop> now that's the error
Feb 19 20:03:56 <GNUtoo|laptop> I forgott to git-add it
Feb 19 20:03:59 <GNUtoo|laptop> I work with branches
Feb 19 20:04:13 <GNUtoo|laptop> sorry for the noise
Feb 19 20:44:19 <GNUtoo|laptop> JaMa, also I've another question
Feb 19 20:44:45 <GNUtoo|laptop> --pagesize=0x800
Feb 19 20:45:01 <GNUtoo|laptop> that's in EXTRA_IMAGECMD_jffs2 for om-gta02
Feb 19 20:45:19 <GNUtoo|laptop> how do I findout the value for gta04?
Feb 19 20:46:45 <anarsoul_> probably same
Feb 19 20:47:04 <anarsoul_> 2k for largepage devices, 512 bytes for small page
Feb 19 20:47:09 <anarsoul_> GNUtoo|laptop: ^^
Feb 19 20:48:21 <GNUtoo|laptop> ok
Feb 19 20:48:42 <GNUtoo|laptop> so it's 2k
Feb 19 20:48:53 <GNUtoo|laptop> because ubifs requires -O 2048
Feb 19 20:48:57 <GNUtoo|laptop> or something like that
Feb 19 20:59:40 <CIA-134> SHR: 03GNUtoo 07meta-smartphone * r47c0654ca5e2 10/meta-openmoko/conf/machine/om-gta04.conf: meta-openmoko: om-gta04: add support for jffs2 images
Feb 19 21:01:28 <JaMa> hah buildhost out of space again :/
Feb 19 21:01:53 <JaMa> and bearstech guys already running ncdu to see that all is in our builddir :/
Feb 19 21:02:02 <GNUtoo|laptop> qouch
Feb 19 21:02:08 <GNUtoo|laptop> s/q//
Feb 19 21:02:08 <apt> GNUtoo|laptop meant: ouch
Feb 19 21:10:52 <JaMa> GNUtoo|laptop: btw: any news about SIGILL issue?
Feb 19 21:11:17 <GNUtoo|laptop> no
Feb 19 21:11:35 <GNUtoo|laptop> there are too many sigkill
Feb 19 21:11:43 <GNUtoo|laptop> which one do you mean?
Feb 19 21:12:05 <lindi-> GNUtoo|laptop: got some bug report?
Feb 19 21:12:28 <GNUtoo|laptop> I don't know
Feb 19 21:12:36 <GNUtoo|laptop> maybe JaMa knows if there is a bugreport
Feb 19 21:12:42 <GNUtoo|laptop> but it's shr userspace stuff
Feb 19 21:12:48 <JaMa> there isn't afaik
Feb 19 21:12:56 <GNUtoo|laptop> ok we should create one then
Feb 19 21:13:01 <JaMa> GNUtoo|laptop: the one causing new images unbootable
Feb 19 21:13:10 <GNUtoo|laptop> JaMa, you're the one with the most information I guess
Feb 19 21:13:19 <GNUtoo|laptop> ok
Feb 19 21:13:24 <GNUtoo|laptop> so the om-gta02 one
Feb 19 21:13:39 <lindi-> sounds like wrong flags given to gcc or something
Feb 19 21:13:39 <JaMa> do we have sigills somewhere else?
Feb 19 21:13:59 <JaMa> lindi-: we switched to gold in last rebuild so it could be caused by that
Feb 19 21:14:07 <GNUtoo|laptop> in browsers
Feb 19 21:14:08 <JaMa> lindi-: but the flags are the same
Feb 19 21:14:11 <GNUtoo|laptop> we have in bash
Feb 19 21:14:12 <GNUtoo|laptop> in opkg
Feb 19 21:14:14 <lindi-> if you just include output of "x/10i $pc" and "info register" it should not be difficult to figure out
Feb 19 21:14:15 <GNUtoo|laptop> in firefox
Feb 19 21:14:17 <GNUtoo|laptop> in midori
Feb 19 21:14:23 <GNUtoo|laptop> in eve
Feb 19 21:14:30 <lindi-> does linking with bfd fix it?
Feb 19 21:14:34 <JaMa> yes but the cause is probably just one
Feb 19 21:15:00 * JaMa don't know I was working on OOM issue, expecting GNUtoo|laptop to handle this one
Feb 19 21:15:12 <GNUtoo|laptop> ok
Feb 19 21:15:19 <GNUtoo|laptop> but I'm not a toolchain expert
Feb 19 21:15:21 <GNUtoo|laptop> I got a trace
Feb 19 21:15:30 <GNUtoo|laptop> but nothing seemed wrong on it
Feb 19 21:15:37 <lindi-> well first you need to figure out why the instruction is illegal
Feb 19 21:15:40 <GNUtoo|laptop> maybe I should show it to khem
Feb 19 21:15:42 <lindi-> and then you need to figure out why it was generated
Feb 19 21:15:56 <GNUtoo|laptop> indeed but I failed at figuring out why it was illegal
Feb 19 21:15:57 <lindi-> both parts should be reasonably easy
Feb 19 21:16:12 <GNUtoo|laptop> on the trace every instrucitons were legal
Feb 19 21:16:12 <lindi-> GNUtoo|laptop: I tried to ask you if the cpu was in arm mode or thumb mod
Feb 19 21:16:14 <lindi-> +e
Feb 19 21:16:22 <lindi-> GNUtoo|laptop: but you quited
Feb 19 21:16:24 <GNUtoo|laptop> ah ok
Feb 19 21:16:35 <GNUtoo|laptop> let me boot om-gta02, I'll look
Feb 19 21:16:40 <lindi-> because the code was definitely thumb code
Feb 19 21:16:52 <lindi-> and if you try to run that in arm mode it will sigill for sure
Feb 19 21:17:07 <JaMa> GNUtoo|laptop: compare working libtifo with broken one to see where instructions starts to differ
Feb 19 21:18:08 <GNUtoo|laptop> ah ok
Feb 19 21:19:18 <GNUtoo|laptop> I'll push a commit first tough
Feb 19 21:23:29 <GNUtoo|laptop> JaMa, if I add a file in om-gta04 override dir it still get machine arch on core based oe?
Feb 19 21:25:09 <JaMa> it should, but better check
Feb 19 21:25:28 <JaMa> someone reported that it doesn't work anymore.. but it worked for me last time I've checked
Feb 19 21:33:29 <GNUtoo|laptop> ok
Feb 19 21:34:27 <GNUtoo|laptop> Architecture: om_gta04
Feb 19 21:34:30 <GNUtoo|laptop> so it's ok
Feb 19 21:39:50 <CIA-134> SHR: 03GNUtoo 07meta-smartphone * r748f398c52f6 10/meta-openmoko/recipes-core/base-files/ (base-files/om-gta04/fstab base-files_3.0.14.bbappend): base-files: add fstab override for om-gta04
Feb 19 21:42:42 <GNUtoo|laptop> maybe it didn't work for machine class or something like that
Feb 19 21:43:00 <GNUtoo|laptop> because here it clearly works
Feb 19 21:43:08 <GNUtoo|laptop> but for palmpre it failed if I remember well
Feb 19 21:43:14 <GNUtoo|laptop> but palmpre is also a machine class
Feb 19 21:45:36 <JaMa> yes it must be MACHINE see utils.bbclass:def is_machine_specific(d)
Feb 19 21:45:54 <GNUtoo|laptop> ok
Feb 19 21:46:28 <GNUtoo|laptop> so I guess with palmpre it interpret that as MACHINE_CLASS instead of MACHINE (palmpre is both MACHINE and MACHINE_CLASS)
Feb 19 21:48:37 <GNUtoo|laptop> ah it should work
Feb 19 21:48:43 <GNUtoo|laptop> anyway time to work on gta02
Feb 19 21:49:06 <GNUtoo|laptop> ah maybe not for palmpre2
Feb 19 21:49:17 <GNUtoo|laptop> because the path is in machine class but not in machine
Feb 19 21:49:18 <GNUtoo|laptop> ok
Feb 19 21:49:43 <GNUtoo|laptop> lindi-, how to see the mode of the CPU, I should info registers?
Feb 19 21:54:43 <lindi-> GNUtoo|laptop: cpsr register has a bit for it
Feb 19 21:54:50 <GNUtoo|laptop> ok
Feb 19 21:54:52 <GNUtoo|laptop> let me look
Feb 19 21:57:19 <GNUtoo|laptop> cpsr           0x60000010	1610612752
Feb 19 21:57:24 <GNUtoo|laptop> I'll look in the arm manual
Feb 19 21:57:30 <JaMa> GNUtoo|laptop: yes palmpre2
Feb 19 21:58:26 <lindi-> GNUtoo|laptop: p/t $cpsr
Feb 19 21:58:31 <lindi-> GNUtoo|laptop: bit more readable that way
Feb 19 21:58:44 <GNUtoo|laptop> ok
Feb 19 21:58:58 <GNUtoo|laptop> $1 = 1100000000000000000000000010000
Feb 19 21:59:36 <lindi-> GNUtoo|laptop: so T=0
Feb 19 21:59:43 <lindi-> GNUtoo|laptop: and you are in ARM mode
Feb 19 21:59:49 <GNUtoo|laptop> ok
Feb 19 21:59:59 <lindi-> GNUtoo|laptop: but the disassembly showed thumb instructions
Feb 19 22:00:12 <GNUtoo|laptop> so adds and such are thumb?
Feb 19 22:00:18 <lindi-> GNUtoo|laptop: yes
Feb 19 22:00:19 <GNUtoo|laptop> I think the arm manual is on my desktop
Feb 19 22:00:21 <GNUtoo|laptop> ok
Feb 19 22:00:28 <lindi-> GNUtoo|laptop: look at the addresses, each instruction is only 16 bits
Feb 19 22:00:35 <GNUtoo|laptop> yes that sounded strange
Feb 19 22:00:41 <GNUtoo|laptop> it jumped of 2 instead of 4
Feb 19 22:00:44 <lindi-> GNUtoo|laptop: not strange, just not ARM
Feb 19 22:00:47 <GNUtoo|laptop> ok
Feb 19 22:01:01 <GNUtoo|laptop> strange means that I didn't understand why
Feb 19 22:01:02 <GNUtoo|laptop> ok
Feb 19 22:01:06 <GNUtoo|laptop> JaMa, ^^^
Feb 19 22:01:13 <GNUtoo|laptop> what should we do now?
Feb 19 22:01:13 <lindi-> GNUtoo|laptop: I hope you learned something new :)
Feb 19 22:01:18 <GNUtoo|laptop> indeed yes
Feb 19 22:01:26 <lindi-> GNUtoo|laptop: figure out what jumped to that routine
Feb 19 22:01:42 <GNUtoo|laptop> else we can just force arm mode
Feb 19 22:01:47 <GNUtoo|laptop> but that's not the right way
Feb 19 22:02:21 <lindi-> GNUtoo|laptop: you can mix them
Feb 19 22:02:26 <lindi-> GNUtoo|laptop: you just need to do it correctly
Feb 19 22:03:00 <GNUtoo|laptop> yes I know
Feb 19 22:03:06 <lindi-> GNUtoo|laptop: http://wiki.debian.org/ArmEabiPort#Thumb_interworking_suggests_armv4t
Feb 19 22:03:12 <GNUtoo|laptop> ok
Feb 19 22:07:36 <GNUtoo|laptop> hmmm
Feb 19 22:07:54 <GNUtoo|laptop> http://www.pastie.org/private/vcl9v7dmiygrwjxkkgzfnw <- I don't see any b beq bne etc... to calloc
Feb 19 22:08:22 <CIA-134> SHR: 03shr-devel 07buildhistory * redbc7ac63cde 10/packages/ (1965 files in 1965 dirs): Build 201202192258 of shr 20120219 for machine nokia900 on shr-chroot
Feb 19 22:08:24 <GNUtoo|laptop> (after the frame 2 switch )
Feb 19 22:14:42 <GNUtoo|laptop> but there is that:
Feb 19 22:14:49 <GNUtoo|laptop>    0x401dd62c <+332>:      ; <UNDEFINED> instruction: 0x00108ef0
Feb 19 22:14:55 <GNUtoo|laptop> maybe the debugging is incorrect
Feb 19 22:15:00 <GNUtoo|laptop> and that is the problem
Feb 19 22:15:24 <GNUtoo|laptop> let me re-download the manual on my laptop
Feb 19 22:24:07 <GNUtoo|laptop> hmmm
Feb 19 22:24:11 <GNUtoo|laptop> the manual says:
Feb 19 22:24:35 <GNUtoo|laptop> A processor in Thumb state can enter ARM state by executing any of the following instructions: BX, BLX, or an LDR or LDM that loads the PC.A processor in ARM state can enter Thumb state by executing any of the same instructions.
Feb 19 22:24:39 <GNUtoo|laptop> but it also says
Feb 19 22:25:02 <GNUtoo|laptop> In ARMv7, a processor in ARM state can also enter Thumb state by executing an ADC, ADD, AND, ASR, BIC, EOR, LSL, LSR, MOV, MVN, ORR, ROR, RRX, RSB, RSC, SBC, or SUB instruction that has the PC as destination register and does not set the condition flags.
Feb 19 22:25:09 <GNUtoo|laptop> which may be our problem?
Feb 19 22:25:24 <lindi-> GNUtoo|laptop: hmm?
Feb 19 22:25:31 <GNUtoo|laptop> blind guess of course
Feb 19 22:25:51 <lindi-> GNUtoo|laptop: my guess is that caller was not built with -mthumb-interwork or something
Feb 19 22:25:57 <GNUtoo|laptop> ah ok
Feb 19 22:25:59 <GNUtoo|laptop> let me check
Feb 19 22:26:21 <lindi-> GNUtoo|laptop: just seeing the code that calls the routine should show it
Feb 19 22:26:36 <GNUtoo|laptop> the problem is that I didn't find it
Feb 19 22:26:43 <GNUtoo|laptop> (the code that calls the routine)
Feb 19 22:27:53 <lindi-> if nothing else you can use http://iki.fi/lindi/git/itrace.git/   to get a full instruction trace
Feb 19 22:28:15 <lindi-> might take a while but if it dies early it might only take a minute or two
Feb 19 22:31:54 <GNUtoo|laptop> hmmm
Feb 19 22:31:55 <GNUtoo|laptop> itrace: itrace.c:108: do_forkexec: Assertion `0' failed.
Feb 19 22:31:55 <GNUtoo|laptop> itrace: itrace.c:370: main: Assertion `!ret' failed.
Feb 19 22:32:35 <lindi-> GNUtoo|laptop: run the testsuite first
Feb 19 22:32:39 <GNUtoo|laptop> ok
Feb 19 22:34:08 <lindi-> GNUtoo|laptop: I think I'll improve that error message a bit :)
Feb 19 22:34:29 <GNUtoo|laptop> also you could sed gcc with $(CC)
Feb 19 22:36:23 <GNUtoo|laptop> ./test0.sh: line 5:   379 Aborted                 ../itrace -o i -m m -s s ./test0
Feb 19 22:36:32 <GNUtoo|laptop> I run it on arm of course
Feb 19 22:38:12 <GNUtoo|laptop> http://www.pastie.org/private/k4wojmyyp2andzpuxilq
Feb 19 22:38:28 <lindi-> GNUtoo|laptop: fixed all these
Feb 19 22:38:42 <GNUtoo|laptop> ok I'll pull
Feb 19 22:38:57 <GNUtoo|laptop> ah it's up to date
Feb 19 22:39:13 <lindi-> GNUtoo|laptop: retry
Feb 19 22:39:18 <GNUtoo|laptop> ok
Feb 19 22:39:34 <GNUtoo|laptop> ok there are new commits
Feb 19 22:39:46 <lindi-> GNUtoo|laptop: oh and hmm, arm support for single stepping was dropped from linux
Feb 19 22:40:01 <lindi-> can't remember exact version now
Feb 19 22:40:24 <GNUtoo|laptop> yes I heard scary stuff on armv4
Feb 19 22:40:24 <lindi-> GNUtoo|laptop: so sorry :/
Feb 19 22:40:29 <GNUtoo|laptop> I think it was on lwn.net
Feb 19 22:40:41 <lindi-> GNUtoo|laptop: you can use gdb to emulate single step
Feb 19 22:40:44 <GNUtoo|laptop> like "you cannot debug stuff reliabily on armv4"
Feb 19 22:40:45 <GNUtoo|laptop> ok
Feb 19 22:40:48 <lindi-> need to script a bit
Feb 19 22:40:49 <GNUtoo|laptop> like nexti
Feb 19 22:41:03 <GNUtoo|laptop> with display set to display assembly
Feb 19 22:41:12 <lindi-> gdb has not used PTRACE_SINGLESTEP ever
Feb 19 22:41:21 <GNUtoo|laptop> ok
Feb 19 22:46:08 <GNUtoo|laptop> http://www.pastie.org/private/peh8yzgtxdnoq8hjdh7f0w
Feb 19 22:46:11 <GNUtoo|laptop> it does it pretty early
Feb 19 22:47:23 <GNUtoo|laptop> what bother me is the warning
Feb 19 22:47:28 <GNUtoo|laptop> about mismatch -dbg
Feb 19 22:47:34 <GNUtoo|laptop> about the library JaMa mentioned
Feb 19 22:48:22 <GNUtoo|laptop> and it's a fresh image with bash-dbg + opkg-dbg pulled inside which should pull all required deps for theses 2 -dbg
Feb 19 22:54:14 <lindi-> GNUtoo|laptop: you might want "stepi" and not "nexti"?
Feb 19 22:55:01 <lindi-> GNUtoo|laptop: since it's quite clear that " 0x4002eeec <_start+12>:  bl  0x40032ed4 <_dl_start>
Feb 19 22:55:10 <lindi-> GNUtoo|laptop: does not jump to  0x7cfc4
Feb 19 22:55:29 <GNUtoo|laptop> ah indeed
Feb 19 22:55:30 <GNUtoo|laptop> sorry
Feb 19 22:56:23 <GNUtoo|laptop> it's late so I make mistakes at this hour
Feb 19 22:57:08 <lindi-> no problem :)
Feb 19 23:40:40 <GNUtoo|laptop> http://www.pastie.org/private/6qazrf8o2q3i0o7vc0c10w
Feb 19 23:46:59 <CIA-134> SHR: 03shr-devel 07buildhistory * r33b29d1f339b 10/packages/armv7a-vfp-neon-oe-linux-gnueabi/webkit-efl/ (3 files in 3 dirs): Build 201202192343 of shr 20120219 for machine palmpre on shr-chroot
Feb 19 23:51:52 <GNUtoo|laptop> lindi-, I'm right before it now
Feb 19 23:51:56 <GNUtoo|laptop> => 0x401786ac:	ldr	pc, [r12, #2404]!	; 0x964
Feb 19 23:52:31 <GNUtoo|laptop> http://www.pastie.org/private/5tcv0rov547uumzppkuxgg
Feb 19 23:52:38 <GNUtoo|laptop>  => I should install libc-dbg
Feb 20 01:05:04 <DocScrutinizer> gnutoo, lindi-: what are you tackling? you know there's a silicon erratum in OMAP3430 (and others?) that basically disallows usage of thumb on e.g. N900?
Feb 20 01:07:24 <DocScrutinizer> as - IIUC - any IRQ would cause a jump from random arm/thumb domain to possibly the opposite state domain code. There's some bit that's not handled correctly and the workarounds are not feasible on N900 due to closed xloader
Feb 20 01:08:09 <DocScrutinizer> sth like that. freemangordon thinks we could implement the workarounds, but I'm unsure about that
Feb 20 01:09:16 <DocScrutinizer> fact is: the stock maemo kernel doesn't work with thumb
Feb 20 01:11:01 <DocScrutinizer> for some funny reason we accidentally got modest (mailer app) compiled with thumb, in CSSU. And it segfaulted left and right like mad
Feb 20 01:11:31 <DocScrutinizer> irreproducably
**** ENDING LOGGING AT Mon Feb 20 03:00:00 2012