3 Sep 23:52
[PATCH 0/10] Sparse linker
From: <alexey.zaytsev <at> gmail.com>
Subject: [PATCH 0/10] Sparse linker
Newsgroups: gmane.comp.parsers.sparse
Date: 2008-09-03 21:55:44 GMT
Subject: [PATCH 0/10] Sparse linker
Newsgroups: gmane.comp.parsers.sparse
Date: 2008-09-03 21:55:44 GMT
Hello. I've been working on a "sparse linker" this summer as my Google Summer of Code project. Wasn't neraly as productive as I hoped, but I've got some results that I would like to share. Moreover, I plan continuing this work, and would like to hear comments on what was done so far. The design didn't change much from what was proposed. We run sparse to generate a "sparse object" file containing a list of symbols, then run the "linker" to unite those object files into bigger ones. This way, in the end we get a file containing all the global symbols appearing in the program. After learning more on the subject, I now agree that we should include the intermediate code representation into the object files. The implementation is built around a generic serialization mechanism [PATCH 01]. It handles many sorts of complex data structures, with pointers, cycles, unions, etc. E.g. it is able to serialize beasts like the sparse pointer lists. The price for this is a four byte overhead prepended to every serializable structure by the allocation wrapper. Also, you have to use a macro when declaring a serializable structure (or an array of such) statically. One limitation I was unable to overcome is the inability to work with structures used both stand-alone and embedded into bigger ones. Luckily, we have no such cases in the sparse codebase. The serializer produces C code, containing the data structures beind serialized. For the structure definitions, the generated code includes the original headers, defining the structures. After serializing a bunch of(Continue reading)
RSS Feed