[01:36:45] <mru> Dark_Shikari: doubtful [01:36:59] <mru> iphone forces you to do yuv to rgb conversion in software [01:37:06] <mru> even though the hardware is perfectly capable [01:39:33] <RTFM_FTW> umm you don't need to do YUV -> RGB in SW [01:39:48] <RTFM_FTW> you could trivially use the ES1 GL path for this [01:39:56] <RTFM_FTW> which I did :) [01:40:26] <RTFM_FTW> in fact *everything* outside of the initial decode could be handled through 3D HW [01:40:43] <RTFM_FTW> even with fixed function ES1 level HW [01:40:49] <mru> the old iphone has some private apis that let you do it efficiently [01:40:55] <mru> those are gone on 3gs [01:41:09] <mru> and you were never allowed to use them [01:41:11] <RTFM_FTW> again you don't need private APIs either [05:43:05] <Dark_Shikari> mru: so if you had hardware for yuv->rgb [05:43:06] <Dark_Shikari> could you do it? [05:43:10] <Dark_Shikari> i.e. given the lack of simd and all that [05:48:32] * pJok waits for Apple to buy ARM and then pull the IP from the market [05:48:46] <pJok> that would be hillarious [05:49:37] <astrange> RTFM_FTW has done it with gl fixed-function, i haven't seen the video bitrate he used (or how accurate the display was) [05:50:13] <Dark_Shikari> pJok: the merger wouldn't be approved [05:51:36] <pJok> Dark_Shikari, would still be hillarious if it actually would get approved [05:54:02] <pJok> Apple could single handedly ruin ARM [06:02:45] <_av500_> they will also impose lifetime limit on ARM cpus you can buy! [06:03:04] <_av500_> sorry, no more washing machine [06:09:31] <Yuvi> Dark_Shikari: borderline, ffmpeg decodes a 480x320 baseline encoded by x264 --tune fastdecode --subme 0 --bitrate 1500 decodes at 23 fps [06:09:55] <Dark_Shikari> how much do you think could be gained via armv6 asm? [06:11:08] <Dark_Shikari> I've seen SWAR implementations of hpel MC [06:11:08] <Yuvi> no clue, I'd doubt more than 10-20% at the really high end [06:11:25] <Dark_Shikari> well I would assume you could probably double the speed of idct [06:11:32] <Dark_Shikari> and speed up mc copy a lot [06:12:10] <Yuvi> mc 0,0 is already optimized iirc [06:12:15] <Dark_Shikari> ah, true. [06:12:27] <Dark_Shikari> That does seem odd though. 3g is not MASSIVELY slower than 3gs when one ignores lack of neon [06:12:44] <Dark_Shikari> and at subme 0, there's nearly no simd-requiring stuff [06:12:48] <Dark_Shikari> just idct really [06:12:53] <Yuvi> no dual issue, 416 vs. 533 MHz [06:12:59] <Dark_Shikari> oh wow, it's only 416mhz? [06:13:03] <Dark_Shikari> so it's not even a fast arm11 [06:13:55] <Yuvi> or did the 3gs get up to 600 [06:15:28] <Yuvi> internet says it does [06:17:04] <Dark_Shikari> hmm, ok [06:17:21] <Dark_Shikari> maybe if they're interested in optimizing for it, I can get some money =p [06:17:46] <Dark_Shikari> I suspect there may be a lot of opportunities like this in the future, e.g. optimizing for specific hardware targets [06:17:49] <Dark_Shikari> Oh, and they also care about the xbox 360 [06:17:58] <Dark_Shikari> which is apparently too slow to do 720p h264 in a single thread [06:29:51] <pJok> _av500_, i thought washing machines mainly used freescale/nec mcu's or 8051 clones [08:30:36] <_av500_> pJok: not the iWash [08:41:46] <pentanol> hi mru, at this weekend you here? [08:41:50] <pentanol> here kind of tiny ffmpeg http://codepad.org/UXO06Dsq [08:51:37] <pentanol> nop, in first not full, there devided http://codepad.org/ZwudRruj http://codepad.org/Q61vrhyM http://codepad.org/XGz2XvZD [09:05:08] <_av500_> pentanol: your main() does nothing? [09:14:42] <pentanol> no it tries allocate everything necessary... avcodec_alloc_context2 but got a segfault [09:16:06] <_av500_> why are you doing this at all? [09:16:28] <pentanol> perhaps I got this because.... http://codepad.org/00E1U4qK [09:16:43] <pentanol> actually it won't work on my arm uC lib [09:17:05] <pentanol> but it compiled well and then static linked well too [09:19:28] <pentanol> llrint and log does into libm, but compiled doesn't see that [09:27:09] <pentanol> so when I've compiled this static, I obtains http://codepad.org/w6oo0Uu5 [09:31:24] <pentanol> here disasm this elf for arm ... http://download255.mediafire.com/aev5gvpe2YDg/fznjtemntly/ffmpeg_tiny.asm.ta... [09:40:04] <pentanol> it crashed everytime when dst= ((uint8_t*)obj) + o->offset; ofset equals 184 [09:57:52] <pentanol> odd it crashes when hits { "iba", 184 } [09:58:21] <mru> pentanol: please try to remove as much as possible [09:58:33] <mru> I expect you to end up with no more than a page [09:58:55] <mru> throw in some printfs so you can trace the code flow [09:58:56] <pentanol> yes, but I can remove [09:59:06] <mru> remove any code that isn't executed before it crashes [09:59:06] <pentanol> because then I can't compiel it [10:15:00] <CIA-7> ffmpeg: stefano * r22958 /trunk/doc/libavfilter.texi: [10:15:00] <CIA-7> ffmpeg: Consistently prefer @var{VAR} over ``VAR'' for indicating filter [10:15:00] <CIA-7> ffmpeg: parameters. [10:40:15] <CIA-7> ffmpeg: stefano * r22959 /trunk/ffserver.c: Statically initialize ffserver.c:config_filename, simplify. [10:40:15] <CIA-7> ffmpeg: stefano * r22960 /trunk/ffserver.c: [10:40:15] <CIA-7> ffmpeg: Implement ffserver.c:report_config_error() and a macro for logging [10:40:15] <CIA-7> ffmpeg: error messages / updating the error count. [10:41:41] <pentanol> mru here disasm and snippet http://download784.mediafire.com/idsqgymgbgTg/yutzmytjodt/ffmpeg_tiny.asm1.t... http://codepad.org/VPcbKPYw [11:15:47] <mru> I said you should be able to reduce it to one page of code [12:06:01] <jai> seriously, how many people use ffmpeg on beos? [12:06:06] <jai> i know one :) [12:06:15] * mru knows none [12:06:30] <mru> if mmu_man used it, he'd keep it from breaking [12:06:53] <jai> mmu_man probably has a box somewhere which runs it [12:07:38] <DonDiego> hmm [12:07:45] <DonDiego> fate looks good except for ia64 [12:08:04] <mru> sparc/linux is dead again [12:08:52] <saste> DonDiego: how is the 0.6 release thing going on? [12:10:02] <DonDiego> /misc/samples/mphq/fate-suite/lossless-audio/inside.tta: Operation not permitted [12:10:10] <DonDiego> mru: permission problem on your avr fate box? [12:10:22] <DonDiego> saste: that's what we're talking about right now :) [12:10:34] <DonDiego> bbl [12:13:01] <mru> DonDiego: compiler bug [13:15:45] <pentanol> hm, I got why it segfault happens on my arm, if I delete everything from static const AVOption options[]={ , but leave just one tiny tool works well without segfault [13:44:42] <nfl> DonDiego, I need your public key [13:44:54] <mru> it should be on keyservers [13:45:02] <mru> fingerprint is in MAINTAINERS [14:00:40] <jai> bleh, maybe we can stop using the soc repo ;) [14:01:11] <mru> git ftw [14:01:38] <jai> indeed, and with all those free git services around [14:14:05] <nfl> DonDiego, I've sent you a request for soc repo access [14:21:48] <jai> why not just host your soc code on github? [14:21:54] <jai> nfl: ^ [14:22:23] <merbanan> nfl: if you can provide commit messages to the soc mailinglist you can use whatever you prefer [16:17:22] <RTFM_FTW> astrange I was fooling around with (700k) WMV2 content... [16:18:04] <RTFM_FTW> rendering this into a 5:6:5 display was "meh" concerning quality... 8:8:8:8 (as one would expect) is far better [16:18:22] <RTFM_FTW> its also considerably slower on older (MBX level) HW tho [17:26:37] <_av500_> 565 is meh [17:32:53] <RTFM_FTW> 5:6:5 is ideal when it comes to saving on render bandwidth [17:33:15] <RTFM_FTW> streaming updates (and streaming RTT) aren't cheap operations [17:33:31] <RTFM_FTW> at least on older, highly limited HW [17:47:57] <BBB> did kshishkov come online today? [17:49:29] <janneg> BBB: no, is he supposed to be back? [17:49:35] <BBB> dunno [17:49:40] <BBB> wanted to ask him some vc1-related questions [18:53:21] <twnqx> mh this sucks [18:53:36] <twnqx> uname() is one of the things you can't hook in libc calls? [18:53:56] <twnqx> i hate writing strace() hooks :X [19:51:50] <ShadowJK> I guess the call gets inlined? [20:00:51] <BastyCDGS> good evening to all :) [20:01:45] <jai> twnqx: do you mean ld_preload'ing a custom uname doesn't work? [20:01:56] <twnqx> jai: excatly. [20:02:19] <twnqx> works for programs i compiled here, but not for two commercial apps [20:02:23] <BastyCDGS> puh that was a day today... [20:02:36] <BastyCDGS> had to fix wires from the power supply of my laptop [20:02:55] <BastyCDGS> they were almost broken, but luckily I got fixing it... [20:03:50] <jai> twnqx: what exactly is the error? [20:04:08] <twnqx> sefault. [20:04:11] <twnqx> segfault* [20:04:55] <twnqx> even when i don't touch the values at all [20:05:19] <jai> twnqx: hmm, is libpthread involved [20:05:32] <twnqx> likely [20:05:43] <twnqx> but i don't have local variables, so it would be reentrant [20:05:56] <jai> twnqx: http://sourceware.org/ml/libc-hacker/2010-04/msg00001.html [20:06:16] <jai> could be related [20:06:33] <twnqx> uhhh [20:06:35] <twnqx> hm [20:06:56] <twnqx> could be, if that init is called before i have time to ldopen glibc... [20:07:07] <jai> yes [20:07:10] <jai> exactly [20:07:22] <twnqx> easy to verify [20:07:47] <twnqx> (although my ptrace-based syscall hooker is almost finished now) [20:08:10] <BastyCDGS> btw, I have a strange problem with ffmpeg today... [20:08:16] <BastyCDGS> it doesn't anymore find the IFF loader [20:08:23] <twnqx> but some of the stack unwinds are weird... [20:08:38] <BastyCDGS> even for ASH.LBM it says couldn't find a suitable loader [20:09:44] <BastyCDGS> I try a complete reset, i.e. a clean git checkout again [20:09:45] <twnqx> jai: http://nopaste.info/c79135d39c.html maybe the first is the pthreads one... [20:09:51] <BastyCDGS> maybe I broke something accidentally [20:12:08] <twnqx> though.. maybe my stack unwinder fails [20:12:37] <jai> twnqx: why this whole exercise btw ;) [20:13:05] <twnqx> because the stupid thing refuse to talk to my jtag programmer [20:13:32] <twnqx> Cable operation is not supported when running the 32-bit version of the application on a 64-bit platform. [20:13:32] <jai> oh [20:14:05] <twnqx> hence... *you run on a 32-bit platform* [20:14:19] <twnqx> and i had most of the code around anyway :P [20:14:27] <twnqx> from some... other exercises [20:16:34] <jai> heh [20:16:49] <twnqx> not touched in two years, but even the vdso code is still correctly recognized [20:27:42] <twnqx> jai: you're right [20:27:58] <twnqx> uname is called before i got to load glibc... [20:27:59] <twnqx> hm [20:29:05] <BastyCDGS> does change of the link libs order help here twnqx? [20:29:15] <BastyCDGS> and/or object files? [20:29:48] <twnqx> since the original program isn't by me i can't change :P [20:30:28] <twnqx> hm, calling dlopen() and friends while being called from libpthreads _init seems not to work [20:32:02] <BastyCDGS> does you call it from a launched thread there? [20:32:07] <twnqx> weird, still crashes [20:32:16] <twnqx> ah well [20:32:19] <BastyCDGS> as far as I know you can't call dlopen like stuff from a thread, you have to use main thread [20:32:20] <twnqx> gonna ignore that. [20:32:45] <twnqx> i'm called from libpthreads _init it seems [20:32:51] <twnqx> before pthreads are even started [20:33:08] <twnqx> anyway, the ptrace method is just more code. [20:33:36] <BastyCDGS> had once a similar problem with wxwidgets wanted to open and init a socket from a non-main thread [20:33:41] <jai> twnqx: maybe apply that patch and use that custom glibc build :) [20:33:41] <BastyCDGS> caused all sort of strange stuff [20:34:32] <twnqx> BastyCDGS: i once wrote code that would spawn thrades to asynchronously handle sockets using signals [20:34:46] <twnqx> it was fun to learn how to do that [20:34:49] <BastyCDGS> moving the socket open/init stuff to main thread and then reading/writing socket from the sub-thread then worked well [20:34:52] <twnqx> until someone ran it on debian. [20:35:02] <twnqx> without NPTL. [20:35:17] <twnqx> and you had no ideas which thread would actually receive the signals >_> [20:35:33] <jai> hah! [20:36:55] <BastyCDGS> it's always a good idea to read docs when using multithreaded stuff if the libs you're using are thread-safe... [20:36:58] <jai> twnqx: anyhow, if you have time try the patched build, it should pretty much work [20:37:07] <twnqx> too lazy [20:37:07] <BastyCDGS> there's still many stuff out there which isn't thread-safe [20:37:16] <twnqx> and also, i want it more universal :P [20:37:39] <twnqx> also, i could just implement uname() by reading from /proc, or even by doing the syscall myself [20:38:00] <jai> twnqx: well, the uname call on init should be in glibc's private namespace [20:38:16] <jai> twnqx: but drepper refused it :/ [20:38:23] <twnqx> > drepper [20:39:29] <jai> twnqx: yeah, you'd probably dlsym it from libc, call it, overwrite machine/whatever and returnb [20:39:45] <twnqx> that's what i tried :) [20:40:16] <jai> in an ideal world it would work pretty well too :) [20:40:29] <twnqx> worked for all functions i tried so far :P [20:40:47] <twnqx> uh what [20:40:56] <BastyCDGS> ehm [20:40:57] <twnqx> something's broken now... [20:41:11] <twnqx> when i change it, the app doesn't even start [20:41:14] <BastyCDGS> just was looking your nopaste stuff [20:41:26] <BastyCDGS> it seems you try to call an x86_64 func from x86_32... [20:41:35] <BastyCDGS> that doesn't work without a wrapper, maybe that is the cause? [20:41:38] <twnqx> mh? [20:41:41] <twnqx> nah [20:41:50] <BastyCDGS> http://nopaste.info/c79135d39c.html [20:41:58] <twnqx> it won't preload to a 64bit anyway [20:42:08] <twnqx> itÄs a 32bit lib in that side of the show [20:42:24] <BastyCDGS> uname(): x86_64 from [20:42:35] <BastyCDGS> it seems to call uname x86_64 from a lib32 [20:42:35] <twnqx> yeah.. that's what the kernel replies back [20:43:08] <twnqx> grrr so if i pretend this machine is i686 the app just terminates [20:44:52] <twnqx> so i have to change the reply on a certain call only *sigh* [20:44:56] <jai> twnqx: time for plan b? :) [20:46:34] <twnqx> jai: not yet [20:46:54] <twnqx> does strcpy copy the final 0 as well? [20:47:03] <BastyCDGS> yes [20:47:24] <twnqx> so that's not the mistake. [20:49:15] <BastyCDGS> I think strcpy internally counts number of characters until \0 and then does a memcpy [20:49:45] <twnqx> yeah, quick testprogram confirms correct operation [20:51:56] <jai> BastyCDGS: not the libc implementation atleast [20:52:17] <BastyCDGS> does it call an intrinsic asm func instead? [20:52:26] <BastyCDGS> a rep movsb loop or sth like that? [20:52:43] <jai> BastyCDGS: no, just a plain old do-while [20:53:11] <jai> with some bounds checking on the src pointer after the copy [20:54:07] <BastyCDGS> btw, anyone checked out my optimization link from yesterday [20:54:18] <BastyCDGS> this guy has very optimized memcpy, strcpy, malloc, etc. stuff [20:54:23] <BastyCDGS> malloc uses mem pooling etc. [20:54:28] <BastyCDGS> might be of interest for ffmpeg ;) [20:56:28] <BastyCDGS> twqnx, could you explain me a bit what you want to do with uname anyway? [20:56:35] <BastyCDGS> I did miss the start of your discussion [20:56:44] <twnqx> i want the program to believe it runs on i686 [20:56:54] <twnqx> (it's a 32bit app anyway) [20:57:01] <BastyCDGS> why that is necessary? [20:57:22] <twnqx> it refuses to what it is supposed to on x86_64 [20:57:56] <twnqx> and the culplrit why it's not working... is apparently the compat libx11 [20:58:12] <twnqx> so... i need to modify my stack unwinder [20:58:16] <twnqx> sucks. [20:58:39] <BastyCDGS> what does your stack unwinder do exactly? [20:58:56] <twnqx> figure out from where the calls originate [20:58:59] <BastyCDGS> I assume you're dealing with plain C in the whole space? [20:59:07] <twnqx> ummmm... [20:59:20] <BastyCDGS> if there's C++ involved you have also to unwind exceptions [20:59:27] <twnqx> ah that you mean [20:59:35] <twnqx> i don't really care [20:59:52] <twnqx> but C++ might explain the [stack] hops [21:00:00] <twnqx> in the backtraces on the pastebin [21:00:11] <BastyCDGS> exceptions have to be unwinded even if you don't use them [21:00:26] <twnqx> i'm unwinding from an assembler perspective [21:00:39] <twnqx> i don't care where it jumped true [21:00:42] <twnqx> through* [21:01:02] <twnqx> i gues longjmp() would break it [21:01:13] <BastyCDGS> that's possible, too. [21:01:21] <twnqx> exceptions shouldn't [21:01:34] <twnqx> it just reads the stack [21:02:22] <BastyCDGS> not 100% sure about this if exceptions are also on the stack, if in doubt try the C++ stuff compile with -fno-exceptions -fno-rtti [21:02:36] <twnqx> i can't compile this [21:02:41] <BastyCDGS> oh [21:02:43] <twnqx> if i could compile it [21:02:44] <BastyCDGS> closed source? [21:02:58] <twnqx> why else would i try to modify the behavior from the outside... [21:03:34] <BastyCDGS> that's right...but could be a learning exercise ;) [21:04:26] <twnqx> it for sure contains Cüü [21:04:28] <twnqx> C++ [21:04:39] <twnqx> since it has libQt and friends [21:04:53] <BastyCDGS> if it uses Qt then it's 100% C++ ;) [21:05:23] <BastyCDGS> maybe you find some infos regarding this with a hexdump of the executable [21:05:33] <twnqx> boring [21:05:33] <BastyCDGS> a lot of compilers put their signature there [21:05:42] <twnqx> i have no intention of even looking at it [21:05:50] <twnqx> i just want it to work :P [21:05:54] <BastyCDGS> if they compiled with exceptions you have to deal with them I'm afraid off [21:06:05] <twnqx> shouldn't matter at all [21:06:12] <twnqx> they'll just be on the stack [21:07:32] <BastyCDGS> I'll do a search on this one moment [21:10:16] <BastyCDGS> the thing is that you can't mix code with -fno-exceptions and code with -fexceptions [21:10:22] <BastyCDGS> even within g++ [21:10:32] <BastyCDGS> so they both interfere somehow [21:11:41] <BastyCDGS> maybe the compiled code also uses -ffast-call [21:12:06] <BastyCDGS> which pushes first two function args in regs instead on stack on x86_32 [21:13:22] <BastyCDGS> http://stackoverflow.com/questions/490773/how-is-the-c-exception-handling-ru... [21:14:32] <BastyCDGS> btw, another idea to solve your problem [21:14:48] <BastyCDGS> do you have an x86_64 with virtualization support (patricia etc.)? [21:15:01] <BastyCDGS> maybe you can use this to make your app thinking it's a x86_32 [21:15:35] <BastyCDGS> this even allows faking CPUID to return a different string [21:15:40] <BastyCDGS> vendor id etc. [21:17:42] <twnqx> hm [21:17:54] <twnqx> i wonder if it *does* cpuid [21:18:03] <twnqx> where's my single stepper... [21:19:14] <BastyCDGS> btw, just looking at your nopaste stuff again, I see 4x [stack] instead of a func name [21:19:22] <BastyCDGS> this could be the exception stuff [21:20:20] <BastyCDGS> at least try to find out which compiler they we're using... [21:21:03] <BastyCDGS> btw, if you're single stepping find the position where it wants to call uname and replace this with a series of NOPs ;) [21:32:11] <twnqx> i could just dynamically scan the program's memory for the x86_64 string and replace it with x86_65 [21:33:06] <BastyCDGS> would be possible, too... [21:34:42] <BastyCDGS> don't forget that the string might be wchar_t [21:35:10] <BastyCDGS> to check for x\08\06\0_\06\04 [21:35:12] <BastyCDGS> so [21:42:11] <twnqx> processtools.c:170: error: generating trampoline in object (requires executable stack) [21:42:12] <twnqx> O_O [21:42:25] <twnqx> now that's a gcc error i never saw before [21:42:39] <BastyCDGS> I see this error now for the 1st time, too ;) [21:42:56] <BastyCDGS> what did you change that this error occurs? [21:43:37] <twnqx> i... moved a function which is a parameter for another function into a third function [21:44:13] <twnqx> http://nopaste.info/0f3e44a760.html [21:46:16] <BastyCDGS> hmm if remembering correct you can't do this... [21:47:01] <twnqx> oh, you can [21:47:07] <twnqx> just not with -Wall -Werror :P [21:48:38] <BastyCDGS> I mean it violates the standard and it seems that gcc gets confused when you do it anyway [21:49:09] <twnqx> processtools.c:170: warning: generating trampoline in object (requires executable stack) - jo it just generates a trampoline (and a warning) [21:49:47] <BastyCDGS> is there any specific reason you want it inside a function? [21:50:09] <twnqx> i want another version of it that needs access to the outer function's parameters [21:50:54] <BastyCDGS> and this really works this way? [21:51:12] <BastyCDGS> why not use just global vars for testing? [21:51:32] <twnqx> because then i have globals vars in the final too :( [21:51:45] <twnqx> and yes, works. [21:52:20] <twnqx> i could just pass a void pointer to the unwind, and make it pass the same to the callback [22:08:46] <twnqx> wow, changing the return "sometimes" causes heisenbugs [22:09:12] <BastyCDGS> quantum physics bugs :D [22:09:23] <twnqx> i just had a heap corruption [22:10:19] <BastyCDGS> btw, there is a language out here which mimics QM that means the code does change by random factors and thus does everything sth. else [22:10:58] <twnqx> hm i wonder how making a child sleep via ptrace and threads interact [22:11:37] <BastyCDGS> you mean sending/receiving signal messages? [22:11:53] <twnqx> well... blocking it on syscall [22:13:43] <BastyCDGS> http://kerneltrap.org/index.php?q=mailarchive/freebsd-hackers/2007/3/31/2196... [22:13:54] <BastyCDGS> look at the post from w0rm [22:29:05] <twnqx> meh [22:30:42] <BastyCDGS> did that help a bit? [22:34:54] <twnqx> not yet [22:35:52] <twnqx> i just realized that the application apparently loads more libs during runtime [22:36:40] <twnqx> and possibly doesn't use the uname output at all [22:37:39] <BastyCDGS> so CPUID? [22:38:24] <BastyCDGS> maybe it's really the best way to use the newer CPU virtualization functions to get this working [22:38:33] <twnqx> it even opens the library that has the error messgae dialog only after the tenth or so uname call [22:38:45] <BastyCDGS> I have no experience regarding coding this but maybe a look into VirtualBox src helps a bit [22:38:48] <BastyCDGS> qemu [22:52:30] <twnqx> funny [22:52:34] <twnqx> in console mode it works [22:52:46] <twnqx> OS platform = i686. [22:52:46] <twnqx> # [22:53:06] <twnqx> so yeah, it uses uname, and if you change it, sometimes it crashes. [22:53:33] <twnqx> tha wouldn't all be so bad [22:53:37] <BastyCDGS> sometimes? that means it basically works with x86_64? [22:54:02] <twnqx> it totally works with x86_64, just actively denies me the functionality i want [22:54:24] <BastyCDGS> why did they implement then such a silly thing? if it works? [22:54:30] <twnqx> well [22:54:36] <twnqx> dunno it it works (yet) [22:54:37] <BastyCDGS> do they want you buying an extra license for 64 bit? [22:54:44] <twnqx> there's one thing: [22:54:56] <twnqx> ERROR:iMPACT - Please update to WinDriver version 8.02 or later. See Answer Record 22648. [22:55:02] <twnqx> (i am running version 10.1) [22:55:05] <twnqx> <_< [22:55:30] <twnqx> because the version they ship [22:55:35] <twnqx> does not compile on 2.6.33 [22:55:49] <BastyCDGS> WinDriver??? [22:55:51] <twnqx> actually, even 10.1 doesn't [22:56:07] <twnqx> unless you modify it slightly (just some checks for includes that moved around) [22:56:35] <BastyCDGS> does it use windows drivers? [22:56:40] <twnqx> apparently some kind of multi-os HAL [22:57:05] <twnqx> i just had to totally rewrite their utterly wrong udev rules file [22:57:28] <twnqx> now... [22:57:43] <BastyCDGS> seems these guys have programmers there that just are able to install sth. like ubuntu ;) [22:57:51] <twnqx> no [22:57:58] <twnqx> sles. [22:58:09] <twnqx> 9.0 it seems [22:58:18] <twnqx> fuck it was more than painful on windows [22:58:29] <twnqx> because the same bullshit checks exist "do not install on 64bit" [22:58:44] <twnqx> then you run it in virtual xp mode (effectively a VM) [22:58:56] <BastyCDGS> win7 virtual xp mode? [22:58:56] <twnqx> and it doesn't work because "can't run in terminal server" [22:58:59] <twnqx> yes [22:59:20] <twnqx> so you can't run the app window only, but if you use the FULL VIRTUALIZED version it works [23:00:35] <BastyCDGS> M$ could start with releasing only 64-bit versions of newer windows versions...I bet in just one week there's no x86_32 only software anymore ;) [23:02:12] <twnqx> the funny thing is [23:02:28] <twnqx> after it detects this driver [23:02:51] <twnqx> and fails to use it because the latest version that is newer tahn the minimum is too old [23:03:00] <twnqx> it recognizes x86_64 again [23:04:52] <BastyCDGS> strange piece of software, really... [23:05:43] <BastyCDGS> but what's the purpose of this tool after all? [23:05:47] <BastyCDGS> what do you use it for? [23:06:45] <twnqx> program the effing FPGAs from that vendor [23:06:52] <twnqx> and [23:06:56] <twnqx> i feel [23:07:04] <twnqx> kinda annoyed, lookinf into my dmesg [23:07:53] <twnqx> the crashes of this program, when i change the name [23:07:57] <twnqx> of the machine [23:08:04] <twnqx> segfault at 6d7c6d60 ip 000000006d7c6d60 sp 00000000ffeb6a0c error 14 in libnss_nis-2.11.so[f4d45000+9000] [23:08:18] <twnqx> it crashes mostly... in libnss_nis [23:08:32] <twnqx> also in libcups, or libXipc [23:08:46] <BastyCDGS> does it call lib32 versions of it? [23:08:50] <twnqx> has to [23:08:54] <twnqx> it's all 32bit [23:09:06] <twnqx> segfault at 56f556e1 ip 0000000056f556e1 sp 00000000ffeea2ec error 14 in 87f5e051180a7a75f16eb6fe7dbd3749-le32d4.cache-3[f4eeb000+6000] [23:09:14] <twnqx> do i even want to know what it's doing... [23:09:55] <BastyCDGS> ehm the stackpointer has an odd address [23:10:03] <BastyCDGS> .....e1 [23:10:10] <twnqx> that's eip [23:10:18] <BastyCDGS> oops right [23:10:42] <twnqx> i BET their sizeof (struct utsname) differs from mine [23:11:04] <BastyCDGS> probably due to alignment rules then [23:11:08] <twnqx> and i'm overwriting their stack [23:11:19] <twnqx> no, because that struct is chaos [23:11:41] <twnqx> let's see what happens with more precide poking [23:16:57] <twnqx> yes. of course. that was the cause of all the crashes. [23:17:00] <twnqx> >_> [23:17:17] * twnqx goes mad [23:18:26] <BastyCDGS> 64-bit aligns different than 32-bit [23:18:31] <twnqx> no [23:18:36] <twnqx> the whole code runs in 32bit [23:18:38] <twnqx> but [23:18:52] <twnqx> there's an extension in gnu mode [23:18:57] <twnqx> a fifth string [23:19:08] <twnqx> i did not set gnu mode [23:19:41] <twnqx> however, instead of grabbing the whole struct from the process' memory, modifying 5 bytes, and writing all of it back [23:19:53] <twnqx> only writing the 5 bytes back makes it very well behaving. [23:20:27] <BastyCDGS> that means much less crashes now? [23:20:39] <twnqx> no crashes. [23:21:34] <twnqx> good, i managed to solve 4 problems in getting this app to work so far [23:21:34] <twnqx> >_> [23:21:55] <BastyCDGS> that's fine... [23:22:06] <twnqx> now for the last [23:22:07] <BastyCDGS> hope that my assists helped you a bit though [23:22:18] <twnqx> a version issue between two binary blobs [23:33:21] <BastyCDGS> I'll go to bed now, very tired now [23:33:39] <BastyCDGS> i wish you a good night and nice dreams and much success with fixing the last issue ;) [23:55:24] <Dark_Shikari> how do I view the kernel syslog?