Airs – Ian Lance Taylor

It’s taken me a while to understand the point of the iPad. I can type on a keyboard faster than I can press keys on a screen, so the iPad would not be useful for me as a computer. And it wouldn’t fit in my pocket, so I wouldn’t carry around the way I carry my phone.

I think I get it now, though. The point of the iPad is to read books, watch videos, and play games. For that, it is looks quite convenient. I can carry it easily from room to room, I can prop it up while I’m eating, I can hold it up while I’m in bed (I assume it’s not too heavy for that). That is, the iPad is not a computer and it’s not a phone: it’s a media consumption device. It’s only real competition at the moment are the various e-book readers, which tend to be limited to just reading books. The first version of the iPad apparently won’t have a camera, and I don’t know whether it has a microphone, but I’m sure that future versions will have both, and that they will be a good way to do video chat.

With that understanding, the complaints I’ve seen about Apple’s tight control over the app store are kind of irrelevant. I don’t want to run arbitrary programs on my books, and I won’t want to run them on an iPad either. When I want to run programs, I’ll use a computer. The app store will be mainly an alternative way to publish information–authors will be able to sell directly to you, rather than going through a publisher.

More troubling are the complaints about Apple’s tight controls over content distribution. If other companies emulate Apple and Amazon, then we are taking another big step toward tight control over copyrighted content and the elimination of some fair use rights. When my only copy of a book is on my Kindle or my iPad, I can’t easily lend it to my friend. When publishers stop making physical books, libraries will become far less useful.

I’ve written before about how copyright will vanish. The iPad points to a way to bring it back: to build copyright controls into the architecture of how people read books. This is the kind of thing Lessig talked about in Code and Other Laws of Cyberspace. Building tight copyright control into a general purpose computer is really really hard. Building it into a closed system like the iPad is much simpler. I’m sure that enterprising people will crack the iPad’s controls, but it remains an open question whether they can crack the controls while still letting the iPad continue to access the various stores that will provide content.

Whether these are reasonable concerns depends entirely on how well the iPad does. I have no plans to buy one myself—I wouldn’t buy one even if I didn’t have these concerns. That is quite different from the iPhone, which I did buy a couple of months after it came out, though I’ve switched to a different phone since. I can’t predict how well the iPad will do; if it is very successful, then we’ll really have to worry about copyright issues in the future.

Coincidentally, I saw the movies The Road and The Book of Eli just a few days apart. They are two different and yet oddly similar visions of what the world will look like after civilization collapses. Men will be predators. Women will suffer. Roads will be left covered with cars. Cannibalism will rise. People will dress in mismatched clothing and gather canned food.

The Road is a far better movie. It is also very sad, which seems a not inappropriate response to the fall of civilization. The Book of Eli has a couple of major story flaws. It also has a character who is obviously under the care of a skilled post-civilization beauty salon that they somehow omitted to mention in the story, a jarring presence in the otherwise apocalyptic landscape. Still, I enjoyed both films.

The zombie film has become a way of metaphorically imagining our fears, which is also what we see in a film like 2012: this is the way the world could end. That doesn’t describe these post apocalypse films, in which the collapse of civilization is only alluded to very briefly and is not shown at all. What are these films about? They both seem to be trying to say something rather than just be a generic action movie.

Both films wind up being about faith. The Road is about faith in humanity, a faith which the protagonist has lost. The Book of Eli, as the name suggests, is about faith in God, a faith which the protagonist has but everybody else has lost. The films are about what you can believe in, who you can trust, after society has fallen apart.

Tying this idea back to my own bête noire, perhaps these films are trying to investigate faith without society because we are lacking faith in society. When you don’t believe in civilization, it seems reasonable to write a story in which there is no civilization, and you explore what you actually do believe in. Of course I’m overthinking this, driven by the coincidence of two such similar movies arriving in the theaters at close to the same time. I doubt there will be another serious post-apocalypse films for several years.

The metaphorical nature of these films is clear when you consider what a collapse of civilization would really be like. It would be nothing like what these films portray. We’ve seen Dark Ages before, and we may again. People didn’t wear mismatched clothing.

I can’t close a post about The Book of Eli without mentioning that it clearly draws on the beginning of The Canticle of Liebowitz, a still-excellent post-apocalypse SF novel.

Lawrence Lessig is pushing for a constitutional amendment to change the campaign financing system. You can sign his petition over at http://action.change-congress.org/amendment.

I think Lessig is right that campaign financing is broken. Elections for national office are very expensive. Politicians spend a lot of their time fund-raising. Jesse Unruh was probably reasonably accurate when he said, about lobbyists, “If you can’t eat their food, drink their booze, screw their women and still vote against them, you have no business being up here” (apologies for the sexism, I’m just quoting). And of course many politicians raise most of their money from small donations. But many do not, and of those who do not, they are far more likely to be elected in the first place if they hold views which are congenial to people who are willing to spend a lot of money on politicians. That increasingly means corporations rather than individuals. That leads to a increasing focus of government on the needs of the wealthy rather than on the needs of the general population. And that leads to an increasing distrust and dislike of government by the general population. And that doesn’t do anybody any good, regardless of one’s political position.

I also think that Lessig is right that the only way to fix campaign financing is a constitutional amendment. The Supreme Court was willing to overturn a hundred years of precedent in their recent decision permitting unlimited corporate speech. Clearly ordinary laws are insufficient. And while the amendment process is obviously very heavyweight, the constitution does after all provide a right of free speech, and campaign financing laws are indeed a limitation on speech; an amendment does not seem inappropriate.

Unfortunately, a constitutional amendment must be voted in by politicians. They would basically be voting away their present support and their future income (many politicians retire to become lobbyists themselves). Passing such an amendment would require overwhelming popular support, and I’m skeptical that that will happen.

All Go code lives in a package. Every Go source file starts with a package declaration which names the package that it lives in. A package name is a simple identifier; besides appearing in a package clause, package names are also used when referring to names imported from another package. That poses the problem of what to do when one program links together two different packages which use the same package name. We can’t expect the author of a large program to be aware of every package that the program uses. However, since Go compiles straight to object files, it’s natural to use the package name in the generated symbol names. How can we avoid multiple definition errors?

The gc compiler comes with its own Go specific linker. That linker now supports automatic symbol renaming at link time based on the name used to import the package. That name is presumed to be unique. This means that all imports of the same package must use the same name to import it; otherwise you might get multiple definitions of a global variable in the package. In the future there may be some need to adjust packages which are distributed without their source code, to ensure that they don’t accidentally alias locally compiled package names.

For the gccgo compiler I have so far avoided using a specific linker, or rather linker wrapper. For large programs gccgo now requires a new option, -fgo-prefix=PREFIX to be used when compiling a package. The PREFIX should be a string unique to that package; for example, in a typical installation, it could be the directory where the package is installed. This gives a unique name used in the compiled code. If the -fgo-prefix option is not used, everything will still work as long as there are not, in fact, two packages with the same name.

Now for something really controversial: what’s wrong with protected symbols?

In an ELF shared library, an ordinary global symbol may be overridden if a symbol of the same name is defined in the executable or in a shared library which appears earlier in the runtime search path. This is called symbol interposition. It is often used with functions such as malloc. A shared library can define malloc and it can have code which calls malloc. If the executable linked with the shared library defines malloc itself, then the version in the executable will be used rather than the version in the shared library. This permits the executable to control the memory allocation done by the shared library, perhaps for debugging or logging purposes. In this regard, shared libraries act much as static archives do.

This has a few consequences. One of them is that within a shared library, all references to a global symbol must use the GOT and PLT, to make the overriding possible. That means that all function calls and variable accesses are slightly slower. Also, some compiler optimizations are forbidden: the compiler can not inline a call to a global symbol, since that symbol might be overridden at run time.

When building a shared library, you can provide a version script which indicates that some symbols are actually not global. That can eliminate the GOT and PLT accesses, but it does not permit the compiler optimizations, and you do have to write that version script and keep it up to date.

When compiling code that goes into a shared library, you can set the visibility of symbols. You can use hidden visibility, which means that the symbol is not visible outside the shared library. You can use internal visibility, which is a lot like hidden—I’ll skip the difference here. Or you can use protected visibility. Protected visibility means that the symbol is visible outside of the shared library, and can be accessed as usual. However, all references from within the shared library will use the definition in the shared library. In other words, the symbol acts more or less as usual, but it can not be overridden. This means that accesses to the symbol avoid the GOT and PLT, and it permits compiler optimizations.

So, what’s wrong with them? It turns out that protected symbols are slower at dynamic link time, which means that programs which use the shared library start up slower. This happens because of the C rule that two pointers to the same function must compare as equal. Since protected symbols are globally visible, you can get a pointer to a protected function in the main executable. You can also get a pointer to that same function in the shared library, of course. Those pointers have to be equal, or the C rule will break.

As noted, the access to the function in the shared library will not use the GOT or PLT. The access in the main executable obviously will use the PLT. How can we make those function pointers equal? We can’t. The executable will have a direct reference to the PLT. The shared library will have a direct reference to the function itself. In neither case will there be a relocation for the reference. So there is no way to make the results equal. (This can work for some targets, but not for ones with simple function references like the x86 targets.)

So, I must have lied. The lie was that there is a case where you need to use the GOT for a protected symbol: when compiling position independent code for a shared library, and taking the address of a protected function, you need to use the GOT. Unfortunately, gcc for the x86_64 target, surely the most widely used gcc target today, gets this wrong: http://gcc.gnu.org/PR19520. This generally reveals itself as an error report when you go to create a shared library: relocation R_X86_64_PC32 against protected symbol `NAME' can not be used when making a shared object.

In any case, when the compiler gets it right, the dynamic linker has to fill in that GOT entry. In order to make the function pointers compare as equal, it has to fill in the entry with the address of the PLT in the executable (or the earlier shared library). But remember, this is a protected symbol, and protected symbols don’t support symbol interposition. So the dynamic linker must only use the PLT of the executable if the reference in the executable refers to the definition in the shared library. That means that when the dynamic linker sees a reloc against a protected symbol in a shared library, it has to do another walk through the executable and earlier shared libraries to see if any of them have a definition for the symbol, in which case the GOT entry must not be set to that earlier PLT entry but must instead be set to the address of the symbol in the shared library itself. This check has to be done for every symbol in the shared library.

Those extra symbol resolution passes means a slow down for every program which uses the shared library, and that is what is wrong with protected symbols.

So how do you get the compiler and linker speedups available by avoiding symbol interpositioning? Unfortunately, you have to give your symbols hidden visibility, which means that they can not be accessed from other modules. Assuming you do want them to be accessed, you need to define symbol aliases for the ones which should be publicly visible. That means that you need to use different names for the hidden symbols. This is awkward at best. Unfortunately I have nothing better to offer. ELF is designed to support symbol interpositioning, and there is no very good way to avoid that without causing other consequences.