[9fans] linking a program to run at a high address

[9fans] linking a program to run at a high address

[ron minnich]

I've done this, and I've forgotten how. I need to tell 6l to link a
program to run at

0x00007f0000000000

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

Re: [9fans] linking a program to run at a high address

[cinap_lenrek]

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 a.out?

--
cinap

Re: [9fans] linking a program to run at a high address

[erik quanstrom]

On Thu May 15 15:03:10 EDT 2014, rminnich@gmail.com wrote:
> I've done this, and I've forgotten how. I need to tell 6l to link a
> program to run at
>
> 0x00007f0000000000
>
> 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.

if you're talking about amd64, i don't think you did.  unless the high
address was a sign-extended 32-bit value. it's a limitation of the architecture.

i suppose you could if the program were RIP-relative, but 6l doesn't do that.

- erik

Re: [9fans] linking a program to run at a high address

[cinap_lenrek]

sorry, wrong terminology. the kernel *maps* text
at UTZERO.

--
cinap

Re: [9fans] linking a program to run at a high address

[erik quanstrom]

On Thu May 15 15:19:39 EDT 2014, cinap_lenrek@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 kernel puts the
> text segment.
> 
> but you probably do not try to produce an a.out?

there is a provision for a 64-bit address in the extended a.out header.  

the problem is the amd64 architecture.  ron actually pointed this out to me
way back, when i thought it would be neater to load the kernel lower
than 0xfffffffff0110000 to allow the kernel to map more than 256mb
of memory, but that's not possible.  if using absolute addressing, the kernel
needs to load at a sign extended virtual address, or below 4g.  if the kernel
were rip-relative, i beleve it could be just about anywhere in the virtual
address space, but i haven't tried this and i may have missed a wherefore
in the intel manual.

it turns out that it's just as easy to load the data at KSEG2, so that's what
is done.  in fact, perhaps KZERO should be moved up to 2⁶⁴-64MB.  then
all the data could be in KSEG2.  clean, if a little unconventional.

- erik

Re: [9fans] linking a program to run at a high address

[cinap_lenrek]

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 <u.h>
#include <libc.h>

void
jump(void *p)
{
	((void**)&p)[-1] = p;
}

void
main(int argc, char *argv[])
{
	char code[8];

	code[0] = 0xCC; /* breakpoint */
	jump(code);
}

--
cinap

Re: [9fans] linking a program to run at a high address

[cinap_lenrek]

> 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

Re: [9fans] linking a program to run at a high address

[ron minnich]

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