Tue, 26 Jul 2011
The things I find myself doing today.
Building debian-installer for m68k
...which requires localechooser
...which build-depends on python-lxml (amongst other things)
...which is uninstallable
...which contains some pythonesque source files that are converted into 6.7M C files (by something called "Cython")
...which is then compiled against python2.6. That takes somewhere between half an hour and one hour on this ARAnyM emulated box (I haven't timed, actually).
...a step which is then repeated for python2.7, and possibly more (I haven't gotten that far yet).
...and this file is located in a directory with dozens more of those pythonesque source files
Looks like this is going to take a while. I should probably look into getting distcc set up.
Mon, 25 Jul 2011
m68k revival
If you thought Debian/m68k was dead and buried and where happy about it, I'm sorry to disappoint you.
The reason m68k had died out slightly was not that we'd lost interest, or that we'd been kicked out of the archive, or anything of the sorts, as I've seen people believe. Instead, the reasons were fully technical: glibc past some particular version needs TLS (thread-local storage) support, which hadn't been implemented for m68k yet, and nobody within the Debian/m68k team had the expertise to work on this. That was all.
Not so long ago, some people within RedHat had started doing a TLS implementation for m68k, however. This was paid for by one of their customers who needed the ColdFire to work, and therefore it was focused mostly on ColdFire. However, ColdFire is close enough to plain old m68k that it was possible to port this TLS support to plain old without too much effort. Unfortunately, most of our machines were pretty much nonfunctional by that time; so in order to get things to work, we'd have to
- Reinstall some of our machines, fix the others, without a functional installer,
- Do the necessary porting and package integration work,
- Rebootstrap the architecture,
- do other things necessary (such as providing a working installer, etc).
Not quite impossible, but still a lot of work that would need someone to put in quite an amount of time. This wasn't something that people in the m68k port could invest; and I'm also not sure we had the necessary skills amongst the team to do the necessary porting.
So the work lay there, and it wasn't being done. Until one Thorsten Glaser, author of a shell called 'mksh' that I hadn't heard of until then, came along, and noted that his mksh package wasn't being built for m68k. Upon investigating, he discovered, as expected, that the port was almost dead. Now most people would leave it at that and decide that they couldn't build for an architecture that wasn't being maintained anymore—and that would be perfectly fine— but not Thorsten. On the brink of death, he almost single-handedly revived the m68k port, and got stuff to work to such an extent that it is now again possible to build a working and fairly up-to-date Linux/m68k ARAnyM virtual machine.
As I'm typing this, my ARAnyM instance is checking out the d-i repository (so I can start building d-i), and building sudo at the same time.
Let's see what comes from this.
Sat, 06 Sep 2008
Bughunting is fun
Two reasons:
- 'foo FTBFS on m68k' is not RC. 'foo FTBFS on m68k because it segfaults during the build since it does bar and baz, which just happens to result in a segfault on m68k at startup but might randomly result in a segfault on every architecture, really' in most cases is.
- It, well, is just fun to debug someone else's code. On m68k, it's easy to do that, too, if you know a bit of assembly language.
Today's (and last week's) bug: #497262. Xemacs21 segfaults at startup on m68k (and FTBFSes because of that), which is RC for m68k. Reason: confusion between a pointer and its value. In other words: the sanity check might succeed, or it might not, depending on your luck. In fact, the first time the code flows through this buggy path, it does not bomb. Once we do get through this bit, it's also very likely that regular error handling will catch it—the only reason why xemacs segfaults here is because we're still in initialization, and the error object in the lisp stuff hasn't been initialized yet, so we get a nice null pointer dereference...
That alone isn't enough to make it RC everywhere, but it's good enough to make it important and fixable for the maintainer. Like I said, fun.
Sorry for those of you who want to release Lenny ASAP, but I think I'll be making your life a bit harder :->
Next week's bug: a similar issue in emacs, or the build failure of ghc6 on m68k, depending on time and complexity.
Wed, 13 Aug 2008
Panther on Debian/m68k.
Some crazy fellow tried to run Mac OS X Panther (that's 10.3 if I'm not mistaken) on a Centris 650 (a 25Mhz m68k). Procedure: run PearPC on an athlon or another insanely fast box to install OS X in an image that PearPC can boot from. Then copy the image to the Centris, run PearPC on that box, and, uh... wait a week for the stuff to boot.
Cute.
Wed, 13 Feb 2008
Quickstep on 2.6
wouter@quickstep:~$ uname -a Linux quickstep 2.6.24-1-mac #1 Fri Feb 1 00:14:53 CET 2008 m68k GNU/Linux
Ph34r my experimental buildd, which will be back... soon.
Unfortunately, doing 'apt-get upgrade' from etch-m68k (the last release to support 2.2, which quickstep was still running) to unstable takes a while. Other than that... yeah!
The update to 2.6.24 had some issues; e.g., the key map wasn't set correctly; also, 2.2 and 2.6 have different ideas about what the system clock is, so it insisted on doing an fsck at boot time initially, which with 18G hard disks takes quite a while on a 25Mhz processor.
Quickstep was one of the last machines that I had which was still running 2.2; unfortunately it took a long time for 2.6 on m68k to become a viable option. Apparently, the issues that existed for Centris 650 (of which quickstep is one) had been fixed a while ago already; I just hadn't noticed. Oops.
My final 2.2-running machine now is barok, my IIci. But that machine isn't very fast anyway, so its lack of 2.6 doesn't really hurt all that much. Having said that, Finn Thain told me he'd be working on IIci support soon, so that issue should be dealt with as well. Whee!
Fri, 04 Jan 2008
Broken C code
A few weeks back, someone asked on debian-68k about an unexpected result of some piece of software when it was compiled on ARAnyM, an m68k emulator that can run Linux.
His initial idea was that this could perhaps be a bug in ARAnyM, since it only occurred to him inside ARAnyM, and not on any of the other architectures he tried. In fact, it was a bug in his code.
Let's have a look at what's going on here. The example program which Sergei provided and which exhibits the problematic behaviour is spread over two files. The first file contains this:
#include <stdio.h>
void *f();
main() {
void *a;
a = f();
printf("%d\n", (long)a);
}
while the second contains this:
#include <stdio.h>
long f();
long f() {
long a = 84;
printf("%d\n", a);
return a;
}
Many people familiar with the C programming language will intuitively expect that this program, when run, will output the following:
84 84
When in fact, when compiled and ran on an m68k machine, the output is as follows:
84 -1072577264
What's going on here? In order to understand that, we have to take a look at the assembly code. This is done by use of "objdump -d", and gives (amongst others) the following output:
800004c4 <main>: 800004c4: 4e56 0000 linkw %fp,#0 800004c8: 61ff 0000 001a bsrl 800004e4 <f> 800004ce: 2f08 movel %a0,%sp@- 800004d0: 4879 8000 05aa pea 800005aa <_IO_stdin_used+0x4> 800004d6: 61ff ffff feec bsrl 800003c4 <printf@plt> 800004dc: 508f addql #8,%sp 800004de: 4e5e unlk %fp 800004e0: 4e75 rts 800004e2: 4e75 rts 800004e4 <f>: 800004e4: 4e56 0000 linkw %fp,#0 800004e8: 4878 0054 pea 54 <_init-0x800002f0> 800004ec: 4879 8000 05aa pea 800005aa <_IO_stdin_used+0x4> 800004f2: 61ff ffff fed0 bsrl 800003c4 <printf@plt> 800004f8: 7054 moveq #84,%d0 800004fa: 4e5e unlk %fp 800004fc: 4e75 rts 800004fe: 4e75 rts
So what's happening here?
- main acquires some stack space, and then (0x800004c8) immediately jumps to a subroutine 26 bytes ahead; our function f.
- f also acquires stack space (0x800004e4), then pushes two addresses on the stack (...4e8 and 4ec), and jumps to the printf function. The first of these two addresses is the constant 84 that is hardcoded in the binary; the second address is our format string.
- f then moves the constant value 84 to the D0 register (...4f8), frees its stack space (4fa), and returns (4fc; the second rts can be ignored, that's a harmless quirk in the compiler).
- main now copies whatever is in the A0 register to the stack (4ce), pushes the exact same format string to the stack (4d0), and again jumps to the printf function (4d6; the difference in hexadecimal values is due to the fact that the bsr opcode uses processor-indirect addressing).
- Finally, main clears up what it's been doing, and exits
The difference should be clear: the f function stores its result value in the D0 register, but main goes looking for it in A0.
The reason for this discrepancy very simple. The m68k processors has three sets of registers: one set is for integer values (D0 through D7), one set is for address values (A0 through A7), and one is for floating-point values (FP0 through FP7). The m68k ABI specifies that integer return values should be stored in integer registers, that address return values should be stored in address registers, and that floating-point return values should be stored in floating-point registers. This makes sense, since register-indirect addressing modes require the address to be stored in an address register; and calculating values requires the value to be stored in either a floating-point or integer register. When main, then, tried to look for a return value in A0, it found something, but obviously not what it should have found...
This issue would have been a non-issue had this function been written the way it should have, like so:
#include <stdio.h>
void* f();
int main() {
long* a;
a=(long*)f();
printf("%Ld\n", *a);
return 0;
}
void* f() {
static long a=84;
printf("%Ld\n", a);
return &a;
}
To close up: there's a reason why compilers emit warnings if you do something strange or "clever". In this particular case, the warning was suppressed, since both files contained a declaration of an f() function, even if the declaration was different. This is a horrible hack that tries to work around those warnings, rendering them utterly useless.
Please, pretty please, with sugar on top: don't do something like that. If you write C code, please compile it with -Wall -Werror, and make sure it compiles that way. If you want to access a function in a different file, create a common header file that both will #include, so that the compiler can notice differences between declaration and definition of a function; and don't expect that something will work because you fixed it for a common and well-known case, because there will often still be other places where your bug will still trigger. In this case, by declaring the function as one returning a long value, they made sure it could not break on 64-bit architectures. However, as shown above, that doesn't make the bug go away...)
Writing clean and portable code is way more fun. Trust me.
Sat, 11 Aug 2007
IRC quietness
Day changed to 09 aug 2007 22:38 -!- foobar ~foobar@XX.XX.XX.XX has joined #debian-68k Day changed to 10 aug 2007 00:08 -!- foobar ~foobar@XX.XX.XX.XX has quit Quit: Leaving Day changed to 11 aug 2007 [13:04] [Yoe(+i)] [6:#debian-68k(+nt)] [Act: 2,7] [#debian-68k]
Really quiet channel, that.
Mon, 18 Jun 2007
Rumours of our death have been greatly exaggerated
No, the m68k port is not dead. Yes, there's an issue with etch-m68k, it mainly being that we haven't set it up properly after these months that we could've done so. That doesn't make it dead. I'd also have appreciated some inquiry from you before sending out such rumours, Joey.
One of my goals for DebCamp/DebConf was to talk about it with the people involved and getting a buildd host up and running. That sortof is underway now. At the same time, it isn't.
In any case, I planned yesterday, after my BoF, to give this the highest priority now. Expect some results RSN(tm).
Sat, 19 May 2007
Updating Debian/m68k patches for gcc 4.2
In a perfect world, software would work perfectly. Unfortunately... well, you know the drill.
Since GCC 4.2 is upcoming, our resident GCC guy doko asked me to find someone to have a look at updating the Debian patches for GCC 4.1 so that they'd apply. Since I need to learn about GCC anyway for the Debian/ColdFire project (which nobody seems to be working on except for me), I started looking into it myself. The procedure is simple enough: uncomment lines in debian/rules.patch, and fix those m68k-specific patches that break.
The first one was easy. debian/patches/m68k-gc.dpatch has been integrated upstream, so is no longer necessary.
The second one was slightly more involved. But only slightly so; the patch tried to change libffi/src/m68k/sysv.S, which had received some three extra lines that conditionally add a .note.GNU-stack section. These three lines weren't there at first; but the .S file was otherwise entirely unchanged, so fixing this was rather easy.
The next one is, uh, pretty hard. gcc/config/m68k/m68k.md is a file of 7k LOC in the GCC-specific "RTL" pseudo-assembly language, which I'm not at all familiar with. Yet, anyway. As a bonus, the first hunk in this file which fails to apply does so because that bit of this code has been changed rather significantly from GCC 4.1 to 4.2. Meaning:
- I need to figure out how this RTL code works
- I need to figure out what this particular RTL code block does
- I need to figure out what the point of this particular patch was
- I need to figure out how to write a patch (in RTL) which semantically does the same thing as what the original patch was doing. Without breaking the changes between 4.1 and 4.2
Wish me luck. At least the first two parts are almost finished; after skimming through chapters 12 and 14 of gccint.info, this hugging code almost makes sense to me.
(oh, and if that last link doesn't make any sense to you, ask me for my fortune file at debconf)
(which is in less than a month! whee! excitement!)
Mon, 09 Apr 2007
Etch m68k
So now that etch is out, m68k is no longer an officially supported port in the latest version of Debian . However, if you have a look at a DMNY[1], you'll see the following:
ncftp /debian/dists > ls Debian3.1r6@ proposed-updates@ Debian4.0r0@ README etch/ sarge/ etch-m68k/ sid/ etch-proposed-updates/ stable@ experimental/ stable-proposed-updates@ lenny/ testing@ lenny-proposed-updates/ testing-proposed-updates@ oldstable@ unstable@
Note the 4th line of output:
etch-m68k/
Yes, that means there is a way out for users of Debian/m68k. The etch-m68k suite will allow us to update patckages for etch on m68k only, much like the AMD64 folks did on sarge. This is necessary, since etch/m68k is a bit too different from 'regular' etch.
Want to help? Head over to debian-68k@lists.debian.org and/or #debian-68k on OFTC. Help is always welcome.
[1]Debian Mirror Near You
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|