you need to give more credit to the compiler :-)
the address I'm using is in the low half of the address space.
But I'll wait for Charles to weigh in and tell us what's what.
ron
> because the immidiate to CALL instruction is 32bit which get sign
> extended to 64bit.
sorry, this isnt true. we do near call (0xe8), which is pc relative but
uses signed 32bit offset. sorry for the noise.
--
cinap
because the immidiate to CALL instruction is 32bit which get sign
extended to 64bit. but the PC *is* 64bit. its just not that easy
to call directly.
#include
#include
void
jump(void *p)
{
((void**)&p)[-1] = p;
}
void
main(int argc, char *argv[])
{
char code[8];
code[0]
On Thu May 15 15:19:39 EDT 2014, cinap_len...@felloff.net wrote:
> that wont work for a.out userspace binary. the kernel loads
> the text segment on fixed base address UTZERO. in the a.out
> header are just longs with the sizes of the segments. theres
> an entry field but it doesnt change where the
sorry, wrong terminology. the kernel *maps* text
at UTZERO.
--
cinap
that wont work for a.out userspace binary. the kernel loads
the text segment on fixed base address UTZERO. in the a.out
header are just longs with the sizes of the segments. theres
an entry field but it doesnt change where the kernel puts the
text segment.
but you probably do not try to produce an
On Thu May 15 15:03:10 EDT 2014, rminn...@gmail.com wrote:
> I've done this, and I've forgotten how. I need to tell 6l to link a
> program to run at
>
> 0x7f00
>
> I've tried various combos of -T, -R, and -D and am failing to get the
> right result ... any hints to revive my poor memo
I've done this, and I've forgotten how. I need to tell 6l to link a
program to run at
0x7f00
I've tried various combos of -T, -R, and -D and am failing to get the
right result ... any hints to revive my poor memory would be welcome.
ron
