**** BEGIN LOGGING AT Thu Feb 25 02:59:58 2010 Feb 25 09:47:16 Noisi: Hey. Did you not get an answer about your mysqlclient question yesterday? Feb 25 09:49:29 only go to #sql , but i got no answer there Feb 25 09:50:01 Bother. Feb 25 09:50:17 Sorry I didn't answer you then: I ended up falling asleep. Feb 25 09:50:38 So my memory is that you had a cross-compile environment but you wanted to try binaries without needing to compile them, is that correct? Feb 25 09:54:12 ogra, it looks like you made all the necessary changes to RootfsFromScratch that we discussed yesterday. Feb 25 09:54:38 mikeul, yes, sorry, i didnt want users to run into problems Feb 25 09:54:58 no problem, that makes sense. Feb 25 09:55:41 I'll just have to find another problem I guess. Feb 25 09:56:13 mikeul: What kind of problem do you like? Feb 25 09:57:22 I'm not really looking for problems, they usually find me. Feb 25 09:59:42 OK. I usually have a reserve of issues available if you're looking for something :) Feb 25 10:00:01 Also, we're having a mini-sprint on Thumb2 porting in about an hour, if you'd like to participate. Feb 25 10:58:33 o/ Feb 25 10:59:30 hmm, all languages are gone from our images again Feb 25 10:59:40 that wasnt the plan :/ Feb 25 11:01:24 * Languages: es xh pt de fr bn Feb 25 11:01:26 * language-pack-${Languages} [i386 amd64 powerpc] Feb 25 11:01:30 oh, sigh Feb 25 11:01:41 hmm...yea... Feb 25 11:02:28 StevenK, ^^^ can you change that post freeze ? Feb 25 11:03:46 ok ... X is crashing badly on me :/ Feb 25 11:03:55 on x86 luckily ;) Feb 25 11:03:58 on armel or x86 ? Feb 25 11:04:00 ah Feb 25 11:04:04 in what way ? Feb 25 11:04:14 i hit ctrl+enter -> boom Feb 25 11:04:19 but only sometimes Feb 25 11:04:26 weird Feb 25 11:04:38 * asac upgrades and hopes there was a fix Feb 25 11:05:35 Hi guys Feb 25 11:05:41 hrm, a rootstock build of ubuntu-netbook hangs reliably in "unpacking iso-codes" Feb 25 11:05:51 hey dmart Feb 25 11:05:54 * ogra wonders why that is Feb 25 11:05:57 hi dmart Feb 25 11:06:17 Hi there, sorry I'm late--- got sucked into a discussion about gdb Feb 25 11:06:20 ogra: did we figure why ooo is pulled in for us now? Feb 25 11:06:32 all fixed and gone :) Feb 25 11:06:40 cooool Feb 25 11:06:56 seems someone added language-support-$lang for all languages and all arches above Feb 25 11:07:25 the -support packages pull in thesaurus and packages that in turn pull in oo.o Feb 25 11:07:42 hmm Feb 25 11:07:45 dmart: You mean you hanged in a discussion with gdb Feb 25 11:07:50 usually we only have -pack and -pack-gnome Feb 25 11:07:52 lol Feb 25 11:08:06 lool: ? Feb 25 11:08:13 dmart: hanging... gdb... Feb 25 11:08:23 oh well Feb 25 11:08:27 lool: well, segfaulting Feb 25 11:08:39 * lool tried to do silly jokes Feb 25 11:08:54 I suspect asac has pity for my jokes Feb 25 11:09:15 * dmart was slow on the uptake Feb 25 11:09:28 Anyone ready to take a look at https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList Feb 25 11:09:35 we can step you through it... Feb 25 11:10:18 so ... Feb 25 11:10:37 i think it would be time to add a column for the current status there Feb 25 11:10:46 or move all the fixed/invalid bugs to a separate table Feb 25 11:10:53 Just drop them? Feb 25 11:11:05 There's wiki history, we don't need to clutter the page for fixed bugs do we Feb 25 11:11:48 not sure Feb 25 11:11:59 dmart: Got blocked on the gcc atomic builtins qemu changes by their ppc maintainer who objects to using them in general, and for ppc in particular; need to redo the patch to only use these for arm/thumb :-( Feb 25 11:12:01 having a page that shows what was done isnt that bad either Feb 25 11:12:50 are there instructions how to do that without gcc atomics? ... /me checks Feb 25 11:13:12 I added some info on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto Feb 25 11:14:15 Still a bit high-level, but better than nothing (hopefully) Feb 25 11:14:22 << On ARMv7, there is a DMB instruction which performs this operation. There is also an MCR p15, ... operation which is backwards-compatible the earlier architecture versions. >> Feb 25 11:14:57 Frankly, I much prefer getting the code to use atomic builtins in, even if only for arm/thumb in my case Feb 25 11:15:02 If you use the atomics, you shouldn't need to use these low-level barriers. Feb 25 11:15:21 ...which are obviously totally arch-specific and non-portable. Feb 25 11:15:24 I think it would help portability to use them by default, but apparently the ppc qemu maintainer prefers holding to comments from 2005 to judge of their usefulness Feb 25 11:15:35 Did you understand why the qemu guys were resistant>? Feb 25 11:15:37 dmart: Yeah we're on the same line Feb 25 11:15:46 dmart: No; let me find the thred Feb 25 11:16:01 http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01142.html Feb 25 11:16:34 Also, it's easier to write buggy atomics code than almost any other sort of code... so the KISS principle definitely applies ;) Feb 25 11:16:41 I checked with another qemu maintainer what he thought of it, and that's the person who suggested I should ask for benchmarks Feb 25 11:17:01 dmart: I'm also pretty sure the code is getting abused in the case of qemu Feb 25 11:17:30 What are atomics used for in qemu anyway? Feb 25 11:17:40 Heck, I could have proposed a patch to use pthread mutxes, that would have been fun Feb 25 11:17:45 dmart: locks Feb 25 11:17:57 Which actually sucks Feb 25 11:17:57 ogra: That's a silly change, sigh Feb 25 11:18:09 Does qemu use multithreading to emulate high-level processes, or something? Feb 25 11:18:10 StevenK, yeah, agreed Feb 25 11:18:24 dmart: Hmm good question, it can emulate two CPUs though Feb 25 11:18:50 I suppose that's only possible with threading or multiple processes, but suspect they use something closer to threading to share memory Feb 25 11:19:13 (it actually uses multiple hosts CPUs when emulating multiple guests CPUs) Feb 25 11:19:30 Right. Well, you can certainly implement fast spinlocks using exclusives and barriers if it's really needed, but that's probably in issue to worry about when the spinlocks are found to be a bottleneck? Feb 25 11:19:53 dmart: Interestingly, the gcc atomics doc recommends not to use them for spinlocks Feb 25 11:20:09 Really, I missed that Feb 25 11:20:12 to not use what? the gcc built ins Feb 25 11:20:16 * dmart looks Feb 25 11:20:17 ? Feb 25 11:20:22 Hmm actually I can't find that reference any more Feb 25 11:20:26 ;) Feb 25 11:20:55 Certainly you should use __sync_lock_* for spinlocks (and not the other funcs) Feb 25 11:21:15 lool: he seems to be fine to use those for thumb2 ... so whats the problem? Feb 25 11:21:31 dmart: Sorry, got confused by this comment http://sourceware.org/ml/libc-alpha/2005-06/msg00132.html Feb 25 11:21:34 They (can) have reduced barriers which make them less of an overhead. Feb 25 11:22:13 dmart: ack, that's what I used Feb 25 11:22:21 dmart: There's no technical problem here, it's mostly politics Feb 25 11:22:32 the ppc maintainer didn't even say which part of the 2005 discussion he was referring to Feb 25 11:22:37 right. Feb 25 11:22:41 but do we care about ppc Feb 25 11:22:41 i.e. performance, should be in libc or whatever Feb 25 11:22:50 they seem to be fine if we submit that for arm Feb 25 11:22:55 Not sure about the comment there--- certainly if you try to take a spinlock and find it's contended, then you can't just loop, because the kernel does not know to schedule the lock holder. Feb 25 11:22:59 asac: Yes, only choice I have for that bug Feb 25 11:23:11 i dont see that beging a problem Feb 25 11:23:20 if folks are happy with their current ppc solution etc. Feb 25 11:23:22 You need to do a thread yield (and even that's inefficient--- the kernel still doesn't know what to schedule next) Feb 25 11:23:24 then let them keep that Feb 25 11:24:27 If we can use the GCC atomics for arm as a first step, that's probably the best approach. They can be optimised later if this looks like a significant benefit. Feb 25 11:24:47 This is certainly no worse than arch-specific implementations in general. Feb 25 11:25:23 I wonder whether they would accept a configure flag to use them Feb 25 11:25:43 #ifdef __arm__ ? Feb 25 11:26:00 I was thinking #ifdef ppc, use_gcc_atomics=no Feb 25 11:26:02 :-) Feb 25 11:26:24 Anyway, it's politics; I will eventually sort it out with upstream Feb 25 11:26:25 Maybe. The other arches might have a view on this though. Feb 25 11:26:27 ok Feb 25 11:26:28 there's no complexity here Feb 25 11:26:40 I wanted to share the discussion with you because of the comments on gcc atomics Feb 25 11:26:53 Sure, that's useful, thanks. Feb 25 11:27:52 The main reason for emphasising the atomics is we want to quickly port to an implementation which works with v7 and Thumb-2, without everyone needing to understand the low-level details (which make my brain hurt a bit ;) ) Feb 25 11:28:07 But anything can be optimised in the future Feb 25 11:28:42 ... Feb 25 11:29:04 asac, all: Should we review through the status of items on https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ? Feb 25 11:29:20 We should identify unfixed or blocked packages. Feb 25 11:29:37 yes Feb 25 11:29:59 so erlang Feb 25 11:30:01 is TODO Feb 25 11:30:20 and gmp still Feb 25 11:30:22 dyfet: ^^ Feb 25 11:30:31 we already discussed gmp last time, so we dont need to do that Feb 25 11:30:56 not sure if we want to go through ffmpeg Feb 25 11:31:01 maybe that would make sense Feb 25 11:31:10 erlang has code-generation. As does parrot. That might be an interesting set of topics. Feb 25 11:31:35 libmad is another candidate Feb 25 11:31:38 ffmpeg has optimised assembler, but that was already dealt with Feb 25 11:31:47 ffmpeg is done? Feb 25 11:31:57 oh right Feb 25 11:32:00 its in the last column Feb 25 11:32:16 It would be good to note on this page whenever something is resolved Feb 25 11:32:51 12:10 < asac> i think it would be time to add a column for the current status there Feb 25 11:32:54 12:10 < asac> or move all the fixed/invalid bugs to a separate table Feb 25 11:33:00 so yes Feb 25 11:33:07 Would it make sense to trawl quickly through the issues with bugs raised to classify them? Feb 25 11:33:32 I can add a resolved column Feb 25 11:33:32 yes Feb 25 11:33:41 ok i can cancel my edit Feb 25 11:33:47 Oh, ok Feb 25 11:33:49 either you say which packages are still not resolved Feb 25 11:33:52 or the other way around ;) Feb 25 11:33:58 Shall we work through? Probably won't take long. Feb 25 11:34:04 ok boost* Feb 25 11:34:08 is done Feb 25 11:34:20 * asac updates the wiki if thats ok Feb 25 11:34:32 ok, if you want Feb 25 11:34:34 cacao-source? Feb 25 11:34:37 thats still open Feb 25 11:34:38 hang on Feb 25 11:34:40 bugwise Feb 25 11:34:52 cacao was recently removed in Debian. Do we need it? Feb 25 11:34:54 boost1.38 is not resolved, what happened to that? Feb 25 11:35:11 Should have been dropped from the archive. Feb 25 11:35:12 Also, the boost1.41 source package was not changed (or this isn't documented in the bug) Feb 25 11:35:15 dmart: its not in the archive anymore Feb 25 11:35:49 https://edge.launchpad.net/ubuntu/+source/boost1.41/+changelog Feb 25 11:35:53 boost is fixed Feb 25 11:36:07 except 1.38 ... but thats not in the archive anymore (too old) Feb 25 11:36:11 38 was dropped, 40/41 was patched Feb 25 11:36:18 Ah, ok, I didn't scroll far enough up the bug. Feb 25 11:36:29 asac, can you note those? Feb 25 11:36:45 yes Feb 25 11:36:52 already done ;) Feb 25 11:37:00 ok, thanks! Feb 25 11:37:15 djvulibre Feb 25 11:37:28 -> done (we checked that last week and evven added a safety belt) Feb 25 11:37:33 erlang Feb 25 11:37:34 -> not done Feb 25 11:37:44 evolution-data-server -> done Feb 25 11:38:16 ffmpeg resolved Feb 25 11:39:08 gcc-4.4 -> was never considered an issue, e.g. is probably right ( Feb 25 11:39:17 gcc-4.4 is under continuous maintenance, so we can mark that an not needing specific action here. Feb 25 11:39:33 ack Feb 25 11:39:41 glib2.0 -> done (atomics by dmart ;)) Feb 25 11:39:56 hmmm, I remember now Feb 25 11:40:08 gmp -> not yet done ... discussed last time; dyfet is on it and i was told he bumped prioritiy now Feb 25 11:40:25 there is an upstream issue with configure tests... Feb 25 11:40:40 for glib? Feb 25 11:40:44 gmp Feb 25 11:40:46 ah Feb 25 11:40:53 politics or technical? ;) Feb 25 11:41:02 yeah... Feb 25 11:41:22 they want never to do try_compile tests, and use the tripplet to identify archs only... Feb 25 11:41:40 they are dumb ;) Feb 25 11:41:43 of course armv7/thumb2 is still "arm" as far as target arch's go... Feb 25 11:41:44 try_compile isnt that bad Feb 25 11:41:46 try_run is bad Feb 25 11:41:53 Hmmm, that only works on x86 where the triplet identifes the arch version... Feb 25 11:41:58 a bit like lool's issue in qemu ;) Feb 25 11:42:31 i dont see that we can do it without try_compile, can we? Feb 25 11:43:01 Just checking the GCC version number might be considered adequate. But try_compile felt more reliable... Feb 25 11:43:12 i agree with dmart Feb 25 11:43:15 me too Feb 25 11:43:19 dmart: what version number is lower bound? Feb 25 11:43:21 4.1.0? Feb 25 11:43:42 I'm assuming lucid GCC is the bound (i.e. 4.4.3) Feb 25 11:44:01 This is not quite true, but it's a reasonable approximation Feb 25 11:44:23 hmm Feb 25 11:44:31 anyway. Feb 25 11:44:37 i think we can use try_compile and just patch it Feb 25 11:44:41 push it to debian Feb 25 11:44:49 and let democracy decide at some point Feb 25 11:45:00 most likely other distros will pick it up too and then upstream is alone ;) Feb 25 11:45:01 (by "reasonable approximation" I mean "safe approximation") Feb 25 11:45:45 okay Feb 25 11:45:48 You might also run nm on libgcc.a. But there's no guarantee the functions won't turn fully into builtins in the future... Feb 25 11:46:07 dyfet: lets just get the work done first and then care about politics Feb 25 11:46:17 also CC me on upstream discussion ;) Feb 25 11:46:22 well, we need to know in this case if we are thumb2 or not otherwise we break debian on armv4, etc... Feb 25 11:46:39 so try_compile seems the safest way by far Feb 25 11:46:48 right Feb 25 11:46:53 reconnect ;) Feb 25 11:47:10 ok, so gmp is in progress Feb 25 11:47:15 dyfet: so you have the patch? Feb 25 11:47:36 I did not do a try_compile patch, but I can do so quickly after the sprint Feb 25 11:47:40 give it to me ... also forward me upstream discussion you had so far ... so i can poke them too ;) Feb 25 11:47:49 ok Feb 25 11:47:58 seems gmp will be fixed today Feb 25 11:48:38 i think the next two are all not-for-us (klibc, libgc) Feb 25 11:48:40 then we have libmad Feb 25 11:48:47 which isnt fixed Feb 25 11:49:04 and llvm Feb 25 11:49:09 Who is handling klibc? Feb 25 11:49:09 both not fixed Feb 25 11:49:45 dmart: i thought it was toolchain/kernel folks Feb 25 11:50:16 actually i thought there are no real issues there. Feb 25 11:50:45 * asac_ grabs the filtered files Feb 25 11:51:13 ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr Feb 25 11:51:15 ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr Feb 25 11:51:16 ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr Feb 25 11:51:18 ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:1: mov pc, r3 Feb 25 11:51:19 ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S: mov pc, lr Feb 25 11:51:21 ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S: mov pc, lr Feb 25 11:51:34 I'd need to look at the source package to see whether that matters. Feb 25 11:52:39 yeah Feb 25 11:52:41 i think it matters Feb 25 11:53:09 Probably we should raise a bug on this one. Feb 25 11:53:41 we should use BX lr Feb 25 11:53:47 unless i am mistaken ;) Feb 25 11:53:49 dmart: right Feb 25 11:54:22 Yes... though I also see #ifndef __thumb__ ... #ifdef __thumb__ ; I don't know which one is actually built Feb 25 11:54:26 (in setjmp.S) Feb 25 11:55:17 hmm Feb 25 11:55:43 bug 527720 Feb 25 11:55:44 Launchpad bug 527720 in klibc (Ubuntu) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527720 Feb 25 11:57:37 dmart: even for thumb it uses #else /* __thumb__ */ Feb 25 11:57:41 mov pc, lr Feb 25 11:57:51 line 78 Feb 25 11:58:04 Yes, that's probably bad (actually, worse than using it in ARM) Feb 25 11:58:22 feels like its safe to use bx lr there Feb 25 11:59:05 Probably yes. I'm wondering whether anyone builds this for Thumb-1 Feb 25 11:59:11 duh Feb 25 11:59:18 that doesn't matter, ignore me ;) Feb 25 11:59:30 mov pc, r3 Feb 25 11:59:42 thats just bx r3? Feb 25 11:59:47 dmart: ? Feb 25 12:00:03 Yes. Feb 25 12:00:21 Providing r3 is derived from a return address Feb 25 12:00:30 (I think that's the case here) Feb 25 12:00:36 latest lucid-netbook-armel+dove doesn't aultomatically login, any idea which user&password should I use? Feb 25 12:00:45 ok let me do the patch then Feb 25 12:00:52 saeed: ubuntu no password Feb 25 12:00:55 dmart: Why wouldn't bx r3 work for an arbitrary branch address? Feb 25 12:01:18 lool: thanks Feb 25 12:01:58 persia: generally, yes. But if the address is detemined by some arithmetic or something the thumb bit (0) might not be set correctly Feb 25 12:02:30 Aha. Thanks for the explanation. Feb 25 12:02:53 http://launchpadlibrarian.net/39762158/klibc-thumb.patch Feb 25 12:02:59 attached to bug 527720 Feb 25 12:03:01 Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720 Feb 25 12:03:41 We still need to check this code isn't built with -marm Feb 25 12:04:03 * dmart greps for -marm Feb 25 12:04:07 not found, probably OK Feb 25 12:04:22 ... Feb 25 12:04:54 dmart: the patch only touched ifdef __thumb__ Feb 25 12:04:55 Ah, actually there is a problem Feb 25 12:05:11 so it should be safe even if we build with -marm ;) Feb 25 12:05:37 dmart: what problem ? Feb 25 12:05:38 The assembler always defaults to ARM Feb 25 12:05:45 right Feb 25 12:05:49 so we build with arm here ;) Feb 25 12:05:57 but we could build with __thumb__ now Feb 25 12:06:00 using this fix Feb 25 12:06:12 This is preprocessed assembler, to __thumb__ will be defined (by the GCC defaults) Feb 25 12:06:17 *so Feb 25 12:06:26 So I think we're OK Feb 25 12:06:44 Actually the functions will get assembled as Thumb because they both have the .thumb_func firective. Feb 25 12:06:47 *directive Feb 25 12:07:01 So this is probably fine. Feb 25 12:07:18 ok Feb 25 12:07:24 so ... i think we are set with this patch? Feb 25 12:07:30 * asac thinks someone should try that out Feb 25 12:07:41 vfork.S needs patching too Feb 25 12:08:34 dmart: i patched that ;) Feb 25 12:08:36 check the patch Feb 25 12:08:40 13:02 < asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch Feb 25 12:08:47 oh Feb 25 12:08:52 i even failed ;) Feb 25 12:09:11 -er- I mean setjmp.S needs patching Feb 25 12:09:55 yes Feb 25 12:10:00 i just failed to produce a patch ;) Feb 25 12:10:02 new patch attached Feb 25 12:10:07 http://launchpadlibrarian.net/39762270/klibc-thumb.patch Feb 25 12:10:56 Yes I think that looks OK. Feb 25 12:11:01 Um, not all the changes in vfork.S from the first patch appear in the second patch. Feb 25 12:11:29 persia: ? Feb 25 12:11:41 I think the second half of the first patch is a headerless non-unified diff of setjmp.S (or something) Feb 25 12:11:43 persia: forget the first patch ... not sure why it was busted Feb 25 12:11:59 right ... what dmart said Feb 25 12:12:06 i am sure i had >> for the second part Feb 25 12:12:10 but apparently i missed -u Feb 25 12:12:12 * dmart is just making it up really Feb 25 12:12:22 Ah. Feb 25 12:12:37 Yes, that does look right (if confusing) Feb 25 12:13:22 so lets continue (i marked it as "has patch" in table Feb 25 12:13:33 libgc is next Feb 25 12:13:39 that one is doko business Feb 25 12:13:55 doko: fixed in 6.8-1.2ubuntu1 Feb 25 12:14:06 so now to libmad Feb 25 12:14:14 what are the hits? Feb 25 12:14:17 * asac_ checks filtered files Feb 25 12:15:09 Looks like an attempt to address an inline data or jump table -- should be a simple fix Feb 25 12:15:13 ./libmad-0.15.1b/imdct_l_arm.S: add r2, pc, #(imdct36_long_karray-.-8) Feb 25 12:15:44 * asac_ looks at porting page Feb 25 12:16:11 so just adr r2, pc ? Feb 25 12:16:15 hmm Feb 25 12:16:16 nope Feb 25 12:16:21 adr r2, imdct36_long_karray-.-8 Feb 25 12:16:23 err Feb 25 12:16:25 adr r2, imdct36_long_karray Feb 25 12:16:59 The trouble is that the pc is a bit unpredictable depending on the code alignment Feb 25 12:17:00 And this is likely to be an alignment issue, right? Feb 25 12:17:04 Search the porting page for "getting the address of local data in the text section" Feb 25 12:17:30 right Feb 25 12:17:46 i think we already discussed that last week ... and i remembered that adr is the right way ;) Feb 25 12:18:07 Looking at it though, I don't know what the data is doing in .text Feb 25 12:18:20 Maybe it would be better to push it into .rodata Feb 25 12:18:25 (it's not code) Feb 25 12:19:01 #define K14 0x0cb19346 Feb 25 12:19:10 if thats used it means we have preprocessed assembler? Feb 25 12:19:16 e.g. we can use #ifdef __thumb__ ? Feb 25 12:20:00 This is really a cleanup change, so we probably don't even need that: we just want to switch from a less portable to a more portable way of addressing the data. Feb 25 12:21:03 are we sure the data isnt modified? Feb 25 12:21:51 I don't think it will be. It's in .text which is not usually made writable Feb 25 12:22:12 My guess is this is a table of precomputed data to speed up the imdct calculation. Feb 25 12:22:35 right Feb 25 12:22:53 The simplest option is to leave it where it is and use adr to address it. Feb 25 12:23:22 heh ;) Feb 25 12:23:33 would be interested in how to do it with rodata though too Feb 25 12:23:41 anyway let me do the patch ... one moment Feb 25 12:24:08 oh .. adr is #ifdef __thumb__ or > armv4t ? Feb 25 12:24:36 dmart: ? Feb 25 12:24:40 I suggest no #ifdef. adr really is the same instruction (just via a pseudo op which makes sure it's really correct) Feb 25 12:25:23 Oh, hang on a minute... this code is built as ARM (as default behaviour again) Feb 25 12:25:55 I suggest to do the adr patch anyway; it's cleaner Feb 25 12:26:22 yeah Feb 25 12:26:22 Or if you want we could try building it in Thumb with Feb 25 12:26:22 ok Feb 25 12:26:24 one sec Feb 25 12:26:25 #ifdef __thumb__ Feb 25 12:26:30 .code 16 Feb 25 12:26:32 #endif Feb 25 12:26:42 .code 16? Feb 25 12:26:51 (Or .thumb, it's a synonym) Feb 25 12:26:53 ah Feb 25 12:26:58 let me first do the adr patch Feb 25 12:27:12 dmart: adr exists since a certain gcc/assembler version or what? Feb 25 12:27:13 I'll work on the other, since I did not explain myself well... Feb 25 12:27:45 http://pastebin.com/M6V3aqiW Feb 25 12:27:54 that would be the libmad adr patch Feb 25 12:27:54 ;) Feb 25 12:28:03 let me attach that to the bug unless you shout Feb 25 12:28:16 asac_: I think adr has been there for a long time; unless someone is using really ancient tools it should work Feb 25 12:28:59 yeah Feb 25 12:29:00 cool Feb 25 12:29:35 ok attached Feb 25 12:30:02 next is llvm Feb 25 12:30:05 * asac_ goes and greps Feb 25 12:30:27 hmm. that seems to be more extensive ;) Feb 25 12:30:48 There is an ongoing bug thread conversation for this one. Basically, the jumping in/out of JITted is not interworking aware. Feb 25 12:30:56 http://paste.ubuntu.com/383646/ Feb 25 12:31:08 :/ Feb 25 12:31:31 ok ... so is on the poirting page what to do for this kind of jump in/out from arm to thumb and vv. Feb 25 12:31:34 ? Feb 25 12:32:14 I think so; I pointed Xerxes Rånby at this, but I haven't had feedback yet. Feb 25 12:32:35 Probably modifications are only needed in a few places, but it will take someone familiar with llvm to know where Feb 25 12:33:58 hmm Feb 25 12:34:30 Probably best to label this as under discussion for now. Feb 25 12:34:38 Do we know the priority of llvm? Does much depend on it? Feb 25 12:35:00 so Feb 25 12:35:01 needs investigation; potential code gen; doko: only used in openjdk-6-jre-zero when using shark Feb 25 12:35:04 thats the comment Feb 25 12:35:08 doko seems to think its ok Feb 25 12:35:12 oh Feb 25 12:35:25 well not sure if one can interpret that out of the comment Feb 25 12:36:01 I think it's not used for openjdk-6 by default (some separate, Thumb EE based JIT is now contributed) Feb 25 12:36:09 ...in openjdk-6 Feb 25 12:36:53 according to our table llvm has zero rdepends Feb 25 12:36:58 (priority) Feb 25 12:38:37 i think we can move on and come back to llvm later Feb 25 12:38:50 mono ... i have the cherry pick staged on my disk Feb 25 12:39:05