From: james.harris.1@gmail.com
On 09/01/2022 11:41, Rod Pemberton wrote:
> On Sat, 8 Jan 2022 13:37:34 +0000
> James Harris wrote:
>
>> The problem is that the main executable needs to have fixups applied
>> before it can be run.
>
> Why do you need fixups applied?
>
> Is this due to the type of executable being used?
>
> Is this due to you moving position-dependent code?
Yes, the code was position-dependent - which, it turns out, is often the
case with executables. Whereas locals may be addressed off the frame
pointer it's fairly normal for addresses of globals not to be relative
to any register but to be hardcoded. For example,
int e;
void f() { e = 0; }
When that's compiled the "e = 0" assignment may become
mov [address_of_e], dword 0
The value 'address_of_e' becomes literally an address; it is only
finalised at link/load time.
...
> What is generating that instruction? Assembly? C code? In both
> cases, I'd think you should be able to convert "gdt" to an indirect
> address or variable. Then, you can play around with what's stored in
> the variable.
It was generated by my compiler.
>
>> For instance, if it includes an instruction such as
>>
>> mov ebx, gdt
>>
>> then that becomes an absolute load:
By "absolute load" I mean where the address is essentially hardcoded in
the object code - except that the linker and/or loader can patch the
address to suit where the code is to be run from.
...
> If you're generating this instruction from assembly, you can change it,
> so it generates an indirect address loading from memory.
>
> If a compiler is generating this instruction, I'd wonder why it was
> doing that, i.e., it should access a C variable stored in memory, i.e.,
> an indirect access. E.g., I'd expect something more like "mov ebx,
> [gdt_pointer]" where gdt_pointer is the memory address where
> the address of gdt is stored. Of course, you can do that for assembly.
But then you would need to know the address of gdt_pointer!
>
> You might be able to fix up issues like a gdt pointing to an incorrect
> location by adjusting either the 16-bit RM segment for CS/DS or the
> 32-bit/64-bit PM base address for CS/DS (stored in the descriptor for
> the PM selector).
>
> That solution will work well for position independent code.
Yes, that would work if using segmentation - although I am using a flat
memory image so it won't work in my case.
...
>> Because of what is, admittedly, a policy decision, i.e. that I don't
>> want to require the code to be in a fixed location
>
> From this, my guess is that it seems like your compiler is producing
> position-dependent code, but you're wanting position-independent code?
> ... If so, that's a problem.
Yes. As I saw it, my choices were:
1. Change my compiler to produce position-independent code.
2. Work out a way to relocate a PE file 'in place'.
3. Work out a way to do the same with an Elf file.
After spending quite a while looking at option 2 I became less and less
certain it would do what I wanted. For example, PE expects sections to
be loaded with different separation than they have in the file and I
needed a loaded image to run 'in place', i.e. without altering such
separations.
Elf may have had its own difficulties so I went for option 1 and decided
to change my compiler. It has been a fair bit of work but the compiler
is now emitting PIC and seems to be doing the job. I just got it working
yesterday.
--
James Harris
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
