Older blog entries for echristo (starting at number 2)

current projects

I've been working on various bits of compiler work for Apple lately. A lot of the public work that's been seen has been of the cleanup variety - fixing up testcase failures from previous releases. However, I've also been working on some bugs relating to the object file format. We've made some recent maneuvers toward having a more sane definition in the toolchain - moving toward linker generated gots and plts, but for a great deal of the existing toolchains this would require a lot of work.

In my previous work I hadn't needed to work around limitations in the object file format - at least not in any great degree. Sure the MIPS ABI could use some changes, and there definitely aren't enough bits in the elf flags field for all of the various instruction sets or processors for the target. In the grand scheme of things these are small peanuts. Mach-O (or macho) is the format that was chosen at work about the time that work on OS X was begun.

Mach-O isn't very flexible. The object file format contains bitfields, not the least of which is for relocations. There are 4 bits of relocations available to a single architecture. For those of you counting at home this gives you 16 relocations. The fact that mach-o by default defines five of them leaves an architecture 11 additional relocations that you can define. Under ELF even the x86 port has 38 relocations, including the ones for TLS. The PowerPC mach-o port is out of relocations completely and yet if we had another 4 bits we probably couldn't do all of the TLS relocations we should have. If we want to get rid of the the compiler generated stubs, or have compiler generated thread-local storage a new way of defining relocations is needed. Or we could move to ELF.

Syndicated 2006-07-24 04:03:00 (Updated 2006-10-26 09:56:58) from eric

Assorted Hacking Lately I've been dealing with the...

Assorted Hacking

Lately I've been dealing with the random bugs of close to release software. The 64-bit eabi stuff is giving UNPREDICTABLE results for a simple:


la reg,0x80000000


macro instruction. Now, I hate macro instructions. There's never an excuse for not saying exactly what you mean if you're going to bother to write assembly in the first place. Especially in cases like this - there are over 2 thousand lines of code in gas just to deal with the la and li macros - and have I mentioned that we don't document them anywhere?


I mean anywhere. One of the canonical bibles of the MIPS architecture is the Kane and Heinrich book. It describes this instruction as "an addiu and an lui if needed". This description is so woefully inadequate that it's hard to specify what the input to the macro should be. If it's an absolute expression like we have above it doesn't specify if we should sign extend the address before adding it. The method of least surprise says that we should. Then there's whether or not we should warn about this questionable behavior. Right now, we do - but only for n64.


The other question is whether or not you should just use the fully qualified address for both 32 and 64-bit cases. This would solve the problem, and is indeed allowed by gas, but it's a little iffy in my book.


I suppose I should start adding all of these things to the wiki page here: MIPS Assembly Programming Wikibook.


Just remember kids, assembler macros are a tool of the devil.

Syndicated 2005-04-11 23:29:00 (Updated 2006-10-26 09:56:58) from eric

First Entry

Trying out the new blog interface over here. Rather disappointed with Livejournal so I decided to move over here. Much nicer for the first few blogs. Hopefully a change of pace on the entries as well.

Syndicated 2005-03-28 06:11:00 (Updated 2006-10-26 09:56:58) from eric

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!