> 1) sometimes I have to lret from a function instead of ret'ing. We
> solved the problem with a medium-rare hack (inserting the lret by
> force after restoring the stack). But the ideal should be to
> declare those subroutines "far" like in old dos days...
> 2) Memory access happens always in your data segment. We would really
> love to be making pointer arithmetics with pointers in other
> segments (gs for example - the one that allows you to access to the
> whole memory, base address = 0 and limit = 4G). Here too the ideal
> things would be to declare those pointers "far" and have them
> handled automagically.
>
> I somehow epidermically feel that the only clean way is to do a
> complete port of gcc/binutils to the new OS. But that's a huuuge chunk
> of work (especially for a person who has very little experience in
> this), and we are soooo near to an ideal solution already.
At least part 1) can be done without specific binutils, and minor
modifications to gcc. You could add an attribute to function
declarations, allowing a notation of
int __attribute__((far)) foo(int param)
{
return -param;
}
To implement that, you'll need to modify gcc/config/i386/i386.c. If
done well, that could become a standard extension, available on all
x86 targets. A quick investigation shows that you'll have to modify
the following pieces (looking at GCC mainline code):
- ix86_valid_type_attribute_p (or ix86_valid_decl_attribute_p?)
- add the instruction to the machine defintion (i386.md), using
define_insn. If you call it insn, say, "long_return", it will give
you a function gen_long_return().
- call gen_long_return() inside ix86_expand_epilogue, iff the far
attribute is set for current_function.
Introducing far pointers is a major undertaking; I recommend an
approach similar to what the Linux kernel did (copy_from_fs,
copy_to_fs, ...). The basic problem is that gcc currently does not
support two different pointer types. You could come up with a new
data-type based on TDImode (see (gcc)Machine Modes), but no port
currently uses that feature.
> SO it is time to knock at the door of GCC gurus. This is my first
> attempt. Maybe a less-linux-specific list is more appropriate, and I'd
> like to receive pointers in that directions. Or, maybe, there is an
> easy solution to get to our desired goal and you may shed some
> light...
The gcc list ([EMAIL PROTECTED]) would be the right place for such a
question.
Regards,
Martin
