Re: gcc48, drmkms issues with i386

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Apr 10, 2014 at 3:40 AM, David Laight <david%l8s.co.uk@localhost> wrote:
> On Wed, Apr 09, 2014 at 09:10:42AM -0500, John D. Baker wrote:
>> On Wed, 9 Apr 2014, John D. Baker wrote:
>>
>> > disk, the last part of the display actually looked like:
>> >
>> > prot_to_real: can't return to 0001296DFn: Diskn
>>
>> Should have been:
>>
>> prot_to_real: can't return to 000129CD Fn: Diskn
>>
>> The amd64-built version behaves the same.  The only difference was the
>> address reported in the message above: 00012D19
>
> All the calls to 'prot_to_real' have to reside in the first 64k of
> the code area.
> The code them bombs out back to the outer loader.

s/prot_to_real/real_to_prot/

http://nxr.netbsd.org/xref/src/sys/arch/i386/stand/boot/Makefile.boot#131

This is quite a hack...

> The linker used to manage that, but it might have been relying
> on the linker putting object files into a section in the order they
> were specified on the command line.
>
> Plausibly prot_to_real could set the real mode $cs value to one
> appropriate for the return address.
> The calls are all from assembler and are followed by a bios call
> and then a call to real_to_prot.
>
> If that were done the /boot code itself could probably be linked with a
> virtual base address of 1MB and run with virtual == physical removing
> the confusing offset.
>
>         David
>
> --
> David Laight: david%l8s.co.uk@localhost