Re: patch: MFSv3 support (libsa) for boot2 (i386)

[Evgeniy Ivanov <lolkaantimat%gmail.com@localhost>]

On Sun, Jan 15, 2012 at 4:40 PM, David Laight <david%l8s.co.uk@localhost> wrote:
> On Fri, Jan 13, 2012 at 06:50:19PM +0400, Evgeniy Ivanov wrote:
>> > The code is linked to an address other than 0x7c00, the first thing
>> > it does is copy itself to that address.
>> >
>> > Are you sure you are disassembling it correctly ?
>> > It looks like you haven't told objdump? it is 16bit code.
>>
>> Yes, I was handling that output by hands. Thanks for the proper command.
>>
>> > That jmp instruction needs to goto address 7c00, the opcode contains
>> > the pc-next relative value, the 7bfe value is just a parameter to
>> > the relocation.
>> > In the final image you have f30c+3+f1-7c00 is 0x7800 which is ok
>> > if the code is expected to relocate itself to 0x7800.
>
>> Why do you refer 0x7800, how it's related to the LOADADDR (0x8800)?
>
> That seemed to be the required LOADADDR to get those instruction bytes.
> But possibly I got the sums wrong!
> (The local file I looked at is old and uses a different LOADADDR.)
>
>> With --adjust-vma=0x8800 I get the thing I understand:
>> 88f1:       e9 0c f3                jmp    0x7c00
>> 0x88f1 + 3 - 3316 (0xf30c) = 0x7c00
>>
>> And I still miss the meaning of relocation value 7bfe.
>> In object file it is
>> 131:   e9 fe 7b                jmp    0x7d32
>> 7d32 = 7c00 + 0x132 (i.e. number of bytes before this command).
>
> If you do an 'objdump -r mbr.o' you'll see there is a pc-relative
> relocation applied to address 132, 'objdump -d' doesn't look at
> the relocations (it would be useful if it did) - so it blindly
> prints the wrong target address.

Useful, thanks!

> The pc-relative relocation will be defined relative to the location
> of the fixup (ie 132 not 134) - so 0x7bfe is needed as a parameter
> not 0x7c00. To save space this value is put into the onject code
> rather than the relocation record.

Aha, I see.

>> And then when link how do we get e9 0c f3? That's the thing I dream to
>> know :-) Because in MINIX I get in final image
>> 88f1:       e9 fe 7b                jmp    0x4f2
>>
>> While preprocessed sources are the same on both systems and compiled
>> with same options.
>
> Something is going wrong with the assemble or link phase - might be
> a buggy version of either the assembler or linker.
>
> Possibly using: jmp .start - $LOADADDR + $BOOTADDR will work instead.

It works, thank you very much! And thanks for all your detailed explanations!



-- 
Evgeniy