Hacker News Reader

Comment by kragen | Hacker News Reader

If you liked this, you'll probably like even more "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" (http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...). Last time I checked, the teensy executable had stopped working around Linux 2.6.26 or 2.6.27, and I don't know why.

Relatedly, I wrote a tiny quasi-Forth in itself that generates ELF executables directly at https://github.com/kragen/stoneknifeforth. Its executables also stopped running around Linux 2.6.27, and I still haven't bothered to figure out why.

View on HN

That's odd. I'm currently running 2.6.32, and it's working fine for me. Maybe it was a transient problem?

Feel free to email me if you notice any of the teensy executables not working. I don't follow the bleeding edge very closely, but I do make a serious effort to keep all of them working.

Works on 3.2.0 too. I do get:

  ~$ file a.out
  a.out: ELF 32-bit invalid byte order (SYSV)

But that's probably to be expected, given how close to the edges of the ELF spec it treads :)

I'm delighted! That probably means SKF is back to working too :)

Edit: Hmm, apparently not — I must be cutting a corner of the ELF spec that teensy isn't, since teensy works for me too. I'm on 3.2.0-35 here.

Agreed. I would heartily recommend reading the article you linked to, I certainly liked it a lot.

The project you've worked on looks interesting, too! It's a little late for me to be reading too much code, but I'll make sure to take a good look at it tomorrow. Thanks for the link.

I hope you enjoy it!

If you'd reported that at the time as a regression, then whatever change had stopped them working would most likely have been reverted. They take binary backwards-compatibility pretty seriously.

StoneKnifeForth is a toy, and the executables it generates were probably actually invalid in some way I don't understand because I haven't read the ELF spec. Preventing the kernel from barfing on them would have an insignificant real benefit, I think, and possibly a significant cost. If we were talking about PulseAudio or something, I would agree, but no.

The obvious first step to reporting the bug (after looking at diffs, which I did try) would be to instrument the ELF loading code with printk calls to explain why it's failing to exec a supposedly ELF executable, so that I could report what it was about the executable it was that made the kernel barf. And then I could fix the executable. I just haven't gotten around to recompiling my kernel with a modified ELF loader.

Being "invalid" doesn't nullify the backwards-compatibility rule - if the kernel accepts a certain kind of invalid ELF file, and people have come to rely on it doing so, then that has become a de facto part of the ABI. "But userspace is buggy!" is not considered a valid excuse.

What does nullify the backwards-compatibility rule is no-one noticing or caring that it has changed.

Reply on news.ycombinator.com