Perl exec

nospam@example.com (Daniel Fischer) — Wed, 23 Jun 2010 08:34:21 +0200

Perl is a popular scripting language in the UNIX world, and there are several ports available for Windows. If your UNIX project uses perl, then porting that code to Windows is fairly painless. Perl doesn't attempt to be entirely portable, but most of the differences are quite obvious.

One that is apparently not obvious is perl's exec function. I've seen this happen to two different projects recently, in short succession. The symptom was that a process was started by a perl script, but no output from it was recorded on Windows. On UNIX, everything worked as expected.

This turns out to be not very complicated. On UNIX, exec is implemented in terms of the execl()/execv() family of syscalls. This means the child process replaces the parent, and any process waiting for that parent automatically waits for the child instead. On Windows, there is no such thing. Windows perl implements exec by spawning a child process and returning control to the parent immediately, which then exits. Any process waiting for the parent regains control instantly and is left unaware of the child. A script written for UNIX will assume that the work is done before it has even started.

There is a simple workaround: Use system (plus exit, if necessary) instead of exec. While the semantics are slightly different from exec, they are at least the same on both platforms; system spawns a new process and then waits for it, returning its exit code. Notice that system has a list form too so you don't need to worry about shell escaping either.

Bad register name "dil" (or "sil")

nospam@example.com (Daniel Fischer) — Fri, 29 May 2009 13:09:23 +0200

This is a piece of code from a project that runs on both the x86 and x86_64 architectures:

 1 static inline int swap_int(int *a, int b) {
 2     asm volatile ("xchg %0, %1" : "+r" (b) , "+m" (*a));
 3     return b;
 4 }

It's fairly easy to see what it does: It swaps two values of type int. This code works perfectly fine on both architectures, provided that you're using a compiler that understands the asm statement, such as gcc. Later, this similar piece of code appears:

 1 static inline int swap_char(char *a, char b) {
 2     asm volatile ("xchg %0, %1" : "+r" (b) , "+m" (*a));
 3     return b;
 4 }

This code still compiles and works just fine. For the most part. But when optimisation is turned on, you may get this error from gcc when building for x86:

Error: bad register name `%dil'

Then you try the same on x86_64 and the error is gone again. No wonder: As opposed to x86, the x86_64 architecture actually has the %dil register.

At first, this appears to be a compiler bug. After all, the compiler is choosing a register that doesn't exist on x86. On closer look, it's a bug in the example code. The issue is that for the b argument, the constraint r is used, indicating that the value should be stored in any general-purpose register. In the first example, this is just fine. All of them will do for 32-bit operations. The second example, on closer examination, actually requires a register whose lower byte is accessible. On x86, there are only four general-purpose registers where this is true: EAX, EBX, ECX and EDX. On x86_64, this is also true for the ESI and EDI registers that are also treated as general-purpose registers on x86.

So what happens is that the compiler correctly chooses the %edi register, which satisfies the r constraint. Later, the xchg instruction is interpreted as referring to two byte-sized values due to the size of the arguments *a and b. Thus, the compiler translates the instruction to its 8-bit form and replaces the register placeholder %0 with the 8-bit form of the %edi register, which is %dil. During assembly, this fails because %dil doesn't actually exist on x86.

If there is a compiler bug, it is only that the error output is misleading. It shouldn't even try to use %dil, it should warn about the real problem.

The real bug is that in the example source, a byte-sized argument was qualified with a constraint that allowed any general-purpose register to be used, where instead, the set should be constrained to registers whose lower byte is available. In gcc, this can be achieved by using the q constraint instead of r.

Portability Blog

Perl exec

Bad register name "dil" (or "sil")