On 13/04/08 04:15 +0200, Segher Boessenkool wrote:
- We need a equivalent solution for the NAME segment in SELF - the
payload chooser must be able to get a human friendly name for each payload without decompressing the entire payload into memory.
If you want this name to be part of the binary (and we can discuss endlessly whether that is a good idea or not -- let's just accept the answer is "yes" :-) ), for ELF, you would do this using a PT_NOTE normally. It's easy to make sure that note sits at the start of the file, too.
But if it was part of the binary, then we would have to decompress at least part of the binary to find it, no?
The only requirement is that there only be one ENTRY segment, which is fine, because thats exactly how many entry points we have.
Would it not make sense to put the entry point info in the file header, not in a segment header, then?
Well - first of all, I think you are confused. There is no SELF file - you won't see a .self file by itself. It is an internal format, suitable only for inclusion in a LAR. This is part of the simplicity. So no file means no file header. But even if there was, I would argue that having the load address in the segment list isn't really hurting us.
It pulls double duty - it identifies the end of the segment list, and it gives us the load address, right when we need it, after we have finished loading the data and code.
We already know what endianism, word size and architecture we're going to run on - SELF is not intended to be portable.
It is nice to have a file header that describes the basic format of the file. You don't *have* to check it if you do not want to.
One important case where you actually want to *use* this info is when you have an architecture that can execute both 32-bit and 64-bit programs.
Again - not a file format, so no file header. And I would argue that if we ever reach the point where we legitmately think that we want to start a payload in 64 bit mode, that the architecture flag should probably be in the LAR header, and not in the SELF.