IRC logs for #openttd.dev on OFTC at 2014-01-03
⏴ go to previous day
00:00:03 <planetmaker> bridges. but that's road, too
00:00:25 <frosch123> yeah, ScriptSign::GetOwner should also distinguish worldgen/gs signs from bankrupt signs
00:01:36 <frosch123> hmm, no, i think there are no special scenedit canals
00:01:43 <frosch123> rivers might be different though
00:02:26 <planetmaker> rivers are not owned by anyone
00:03:33 <frosch123> yeah, it's a different issue. we can add ScriptTile::IsRiver and ScriptTile::IsCanal as well or so
00:04:01 <frosch123> though there is ScriptMarine::IsCanalTile
02:00:35 *** JGR has joined #openttd.dev
03:21:42 *** TheIJ has joined #openttd.dev
03:21:42 *** juzza1 has joined #openttd.dev
03:21:42 *** planetmaker has joined #openttd.dev
03:21:42 *** fonsinchen has joined #openttd.dev
03:21:42 *** Hirundo has joined #openttd.dev
03:21:42 *** kinetic.oftc.net sets mode: +vv planetmaker fonsinchen
09:01:36 *** adf88 has joined #openttd.dev
09:01:36 *** ChanServ sets mode: +v adf88
09:38:51 *** ChanServ sets mode: +v Rubidium
09:38:54 <Rubidium> please post them, together with the compiler version in the thread in the development section
09:39:34 <Rubidium> I don't have those warnings with gcc 4.8
09:40:58 <planetmaker> from what I gather reading the code the warnings are pointless. They are used ininitialized - but only be be assigned a value inside the function.
09:43:00 *** Alberth has joined #openttd.dev
09:43:00 *** ChanServ sets mode: +v Alberth
10:34:08 *** JGR_ has joined #openttd.dev
10:52:15 *** Eagle_Rainbow has joined #openttd.dev
10:52:15 *** ChanServ sets mode: +v Eagle_Rainbow
10:52:40 <Eagle_Rainbow> happy new year to everyone
10:56:00 <Eagle_Rainbow> for me the new SSE2 blitter causes a segmentation fault on startup - already known here?
10:59:08 <Eagle_Rainbow> env: gcc 4.4.5 (yes, I know: old), /proc/cpuinfo states SSE and SSE2 only; backtrace is very vague:
10:59:18 <Eagle_Rainbow> __do_global_ctors_aux() at 0xaaa116
10:59:21 <Eagle_Rainbow> _init() at 0x619f1b
11:02:02 <Eagle_Rainbow> I was able to bisect the issue to be introduced with r26211 (which is no surprise, though)
11:06:55 <Rubidium> Eagle_Rainbow: you forced the sse2 blitter?
11:07:49 <Eagle_Rainbow> nope - appears to be on by default (at least this part)
11:08:57 <Eagle_Rainbow> My gutfeeling tells me: Has something to do with HasCPUIDFlag, as even new Blitter_32bppSSE2() isn't called yet...
11:09:09 * Eagle_Rainbow is trying to debug to give some more hints
11:11:22 <Rubidium> my gcc 4.4.5 binary works just fine
11:16:18 <Eagle_Rainbow> apparently void ottd_cpuid(int info[4], int type) is somehow broken
11:16:34 *** adf88 has joined #openttd.dev
11:16:34 *** ChanServ sets mode: +v adf88
11:16:43 <Eagle_Rainbow> I replaced the asm function with constants valid for my machine and it worked again...
11:18:32 <Eagle_Rainbow> could it be that the stack frame gets broken somehow?
11:19:24 <Rubidium> might be; my asm fu comes basically from copy-pasting it from somewhere
12:11:13 <Eagle_Rainbow> @Rubidium: How did you get to the point that the BX register is being clobbered?
12:20:57 <Eagle_Rainbow> mmh.. I think you misunderstood this statement there...
12:21:44 <Eagle_Rainbow> I have reimplemented the CPUID function how I would do it and got totally different results - but those values I would expect to see on my box...
12:25:24 <Rubidium> with your code: /tmp/1.3/src/cpu.cpp:105: error: can't find a register in class 'BREG' while reloading 'asm'
12:26:00 <Rubidium> the 1.3 is a misnomer; it's actually trunk
12:27:11 <Rubidium> anyhow, your code is roughly the same as the code I used to have
12:27:32 *** adf88 has joined #openttd.dev
12:27:32 *** ChanServ sets mode: +v adf88
12:28:17 <Eagle_Rainbow> ok, lemme better understand that BREG error there..
12:28:55 <Eagle_Rainbow> ah! now, I understand: PIC != PIC
12:33:52 <Eagle_Rainbow> BTW: pushl %%ebx seems to be enough; you don't need %%rbx
12:34:59 <Rubidium> rbx is needed for 64 bits
12:37:10 <Rubidium> do you create 32 bits or 64 bits binaries?
12:39:45 <Eagle_Rainbow> ELF 64-bit LSB executable, x86-64
12:40:04 <Eagle_Rainbow> concerning ebx: yep... got the point
12:40:11 <Eagle_Rainbow> and most likely also found your "template" :)
12:42:20 <Eagle_Rainbow> will do, gimme a second; I want to see something else first
12:44:25 <Eagle_Rainbow> That's hot: at the end of ottd_cpuid() I added a "printf ("test");" just for the sake of having a proper breakpoint - now it works. Without it (just commented it out): back to the old problem
12:44:33 <Eagle_Rainbow> perhaps an inlining issue?
12:44:52 <Rubidium> it shouldn't be inlined, unless you're using LTO or something similar
12:44:53 * Eagle_Rainbow used the old code as of r26211
12:46:00 <Rubidium> r26211 has the anti 'clobbering' code already
12:46:50 <Eagle_Rainbow> yep - and based on a git bisect it was the location where my problem has been introduced
12:46:59 <Eagle_Rainbow> (first commit with the error)
12:47:38 <Rubidium> since the code is already used before that
12:48:07 <Rubidium> r26205 to be precise, but not that early in the execution of the game
12:53:25 <Eagle_Rainbow> Had a look at the generated assembler code of both versions: besides some necessary differences of stack frame handling, I don't see a change...
12:55:23 <Eagle_Rainbow> But I don't understand why
12:57:19 <Eagle_Rainbow> Especially as "xchgl %%ebx, %1 \n\t" is being translated into "xchg %ebx,%ebx" which is trivial
13:00:12 <Rubidium> maybe it becomes that when PIC isn't used?
13:01:33 <Rubidium> i.e. it becomes another e?x when PIC isn't in use?
13:01:34 <Eagle_Rainbow> perhaps - that the coding of r26211 is thought to be PIC-enabled, but the xchgl version is understood that it won't do it...
13:01:46 <Eagle_Rainbow> don't think so:
13:01:55 <Eagle_Rainbow> I am doing objdump -sD cpu.o
13:02:10 <Eagle_Rainbow> on what the Makefile has created...
13:03:37 <Eagle_Rainbow> If I may have a call: I would prefer the xchgl version in trunk, though I don't get it entirely, yet :)
13:04:31 <Rubidium> it's xchg %ebx,%esi for me
13:05:30 <Rubidium> hmm... so it copied the code three times
13:09:18 <Eagle_Rainbow> strange things happen here as well: in the original version (push-variant) produces a "mov %eax,%esi" right after the "pop %rbx"
13:09:34 <Eagle_Rainbow> wouldn't this kill the stack indicator?
13:10:04 <Rubidium> it's xchgl %ebx, %esi on the platform where the BREG error happens on
13:11:14 <Rubidium> I reckon that xchgl %ebx,%ebx is just effectively a no-op, so it can behave like only a cpuid in some cases
13:12:03 <Rubidium> but in other cases it can be used to temporary store the ebx value into some other register, and then once cpuid has run swap ebx and the other register so the original ebx is returned
13:17:28 *** frosch123 has joined #openttd.dev
13:17:28 *** ChanServ sets mode: +v frosch123
13:33:16 *** Alberth has joined #openttd.dev
13:33:16 *** ChanServ sets mode: +v Alberth
13:41:31 *** adf89 has joined #openttd.dev
14:11:32 <frosch123> silly cpuid, fails on random machines?
14:17:20 <Eagle_Rainbow> no, it's not cpuid itself...
14:17:35 <Eagle_Rainbow> it more looks that this asm stuff is quite shaky
14:18:16 <frosch123> yeah, now it works on your machine, on mine, on rb's... but fails on the farm again :p
14:18:41 <Eagle_Rainbow> could you send me the log again?
14:19:58 <frosch123> does not look particular useful though
14:20:16 <frosch123> maybe some important registered is destroyed, which makes it crash later
14:20:17 <Rubidium> a crash in the file scanner?
14:21:51 <Rubidium> gcc 4.4 crashes, 4.6-4.8 don't
14:23:09 <Rubidium> gcc 4.4 debug=3 runs
14:23:33 <Eagle_Rainbow> do we have a log from that same box but on r26218?
14:25:34 <Eagle_Rainbow> ok, that means that this compiler version is not able to digest our xchg variant properly...
14:25:47 <Eagle_Rainbow> seems like we fixed the symptom, but not the root cause :(
14:27:09 <Eagle_Rainbow> are we able to somehow get the file objs/debug/cpu.o from #3016?
14:37:53 <frosch123> : "0" (type) <- what does the "0" mean, i only know "a"
14:38:56 <Rubidium> copy-pasted from... somewhere
14:39:17 <Rubidium> lets see if changing 0 to a does anything
14:39:43 <Eagle_Rainbow> "take the same register as the zero-ist constraint"
14:40:06 <Eagle_Rainbow> frosch123: would be the same in your case
14:41:28 <Rubidium> 0 or a, crashes in both cases
14:51:49 <Eagle_Rainbow> However, how, EBX is being clobbered, but we did not explain it
14:52:54 <Eagle_Rainbow> even worse: it can't guess that it's clobbered, so the contents may be voided and cause any arbitrary inconsistency
14:53:57 <Rubidium> hmm, I also see bits of cpuid code that use a different bit of code for x86 PIC than non-PIC x86 or x86_64
14:54:35 <Rubidium> might that be the right way?
14:55:05 <Eagle_Rainbow> What's the difference you see?
14:56:33 <Eagle_Rainbow> the major difference between the farm-box and mine is, that I am using gcc 4.4.5, the farm-box 4.4.7
14:59:41 <Rubidium> (seems to build on i386 OSX)
15:00:37 * Eagle_Rainbow will try if it breaks my setup here
15:00:46 <Rubidium> what does the whole volatile asm do?
15:01:01 <Eagle_Rainbow> you mean "volatile" as statement?
15:01:15 <Eagle_Rainbow> s/statement/modifier/
15:01:32 <Rubidium> __asm__("cpuid;" vs __asm__ __volatile__(...
15:01:57 <Eagle_Rainbow> "volatile" instructs the gcc compiler that it may not change the sequence of this block
15:02:08 <Eagle_Rainbow> for reasons of optimizations
16:44:43 *** adf88 has joined #openttd.dev
16:44:43 *** ChanServ sets mode: +v adf88
16:50:56 *** Alberth has left #openttd.dev
17:53:17 <Rubidium> planetmaker: can you check whether that patch from the blitter thread helps?
18:29:33 <planetmaker> Rubidium, which patch?
18:30:05 <planetmaker> ah, wrong thread :)
18:34:19 <planetmaker> Rubidium, yes, it actually does help
18:34:44 *** Alberth has joined #openttd.dev
18:34:44 *** ChanServ sets mode: +v Alberth
18:39:24 <Rubidium> planetmaker: could you commit it then?
18:45:09 *** adf88 has joined #openttd.dev
18:45:09 *** ChanServ sets mode: +v adf88
18:45:57 <planetmaker> It smells very much like code duplication
18:46:24 <Rubidium> sadly enough... that's basically the point
18:46:50 <Rubidium> for the different SSE ones you have N variants where each variant is the previous plus an improvement
18:47:09 <Rubidium> and the improvement is usually a slightly more performant SSE instruction
19:13:45 *** JGR has joined #openttd.dev
20:21:13 *** Eagle_Rainbow has joined #openttd.dev
20:21:13 *** ChanServ sets mode: +v Eagle_Rainbow
20:21:42 <Eagle_Rainbow> I slowing begin to understand what the CPUID problem really is about...
20:23:21 <Eagle_Rainbow> But if they do (in the case of "Another version of that:"), they explicitly specify which registers shall be used
20:23:50 <Eagle_Rainbow> They don't use "=r" but only "=D" which takes away one degree of freedom to the compiler.
20:24:40 <Eagle_Rainbow> Here on my local box, it caused big trouble, as my compiler - by chance - took EBX (as I did not enable PIC) for this "=r"
20:25:24 <Eagle_Rainbow> This resulted in the following nonsense code: push %rbx; cpuid; mov %ebx, %ebx; pop %rbx
20:26:22 <Eagle_Rainbow> => the value of ebx is gone with the wind, and later on the registers are wrong which leads to writing to *(NULL)
20:27:07 <Eagle_Rainbow> I fear that with the current r26224 it can still be the case.
21:16:19 *** Alberth has left #openttd.dev
21:24:04 <Rubidium> what is, commonly, for PIC in ebx in i386, is in a new register rip in x86_64
21:26:01 <Rubidium> so the whole mess isn't necessary for x86_64
21:28:25 <Eagle_Rainbow> ok, that I did not know
21:28:35 <Eagle_Rainbow> then we get rid of it...
21:31:26 <Eagle_Rainbow> ... and then we can revert back to xchg... mmmh
21:35:12 <Eagle_Rainbow> In case of PIC i386,however, it would be very unlikely that the compiler chooses EBX for the yet-to-define register... the coding is not very self-explaining here
21:42:40 <frosch123> there are some myths that gcc would have a "cpuid.h", but i do not have it either
21:43:15 <Eagle_Rainbow> I am convinced in the meantime :)
21:43:36 <Eagle_Rainbow> You also see there very well, that they "#ifdefined(__i386__)&&defined(__PIC__)" it
21:44:25 <Eagle_Rainbow> but putting it in a macro, doesn't make it easier to understand either ;)
21:44:28 <frosch123> i have also seen versions which force it to use edi, i.e. "=D"
21:44:40 <frosch123> they use "mov" instead of "xchg" then
21:45:05 <Eagle_Rainbow> yes, has the same effect
21:45:07 <frosch123> hmm, do they? maybe i misremember
21:45:32 <Eagle_Rainbow> There are multiple ways how to get around the issue
21:45:55 <Eagle_Rainbow> The big point is that you have to do the "mov" or "xchg" trick, if it's i386 and PIC-enabled.
21:46:03 <Eagle_Rainbow> In all other cases, you should not do it.
21:46:49 <Eagle_Rainbow> If you do it, you may also hit the wall, if you are using "=r"
21:47:33 <Eagle_Rainbow> which is what happened this morning to me.
21:48:56 * Eagle_Rainbow is asking himself if he shall played the lottery this week - chances might be good :D
22:57:05 *** Zuu has joined #openttd.dev
continue to next day ⏵