On 28 March 2014 20:08, Michael Casadevall
<michael.casadev...@linaro.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
>> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>>
>>>
>>> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
>>>> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael Casadevall
>>>> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>
>>>>> As I've made a fair bit of headway since LinaroConnect, I
>>>>> wanted to drop a line on my current progress with porting
>>>>> TianoCore to KVM
>>>>>
>>>>> Summary (tl;dr version):
>>>>>
>>>>> KVM can start TianoCore, and boot all the way to shell, and
>>>>> access HDDs via VirtioBlk. We can start grub and
>>>>> successfully retrieve files from ext partitions, load a
>>>>> device tree, and start the kernel. The kernel runs through
>>>>> most of the EFI stub, but falls over during
>>>>> ExitBootServices()
>>>>
>>>> Thanks for providing this status!
>>>>
>>>>>
>>>>> Long Version:
>>>>>
>>>>> So, after much blood sweat and tears, we're finally at the
>>>>> point of trying to actually start a kernel, though this (for
>>>>> the moment) remains an elusive goal. The current problem is
>>>>> that once we call EBS(), we get an exception from EFI with no
>>>>> Image information, which means the exception handler doesn't
>>>>> know where it came from. After several seconds, we get a
>>>>> second exception from within DxeCore, and then EFI falls
>>>>> over.
>>>>>
>>>>> Debugging EFI is difficult and error prone, combined with
>>>>> limited debug facilities from the gdb-stub in QEMU (no
>>>>> breakpoints), and no decent way to load all of EFI itself
>>>>> (you have to run add-symbol-file manually with the output of
>>>>> commands printed on the console; supposedly its possible to
>>>>> generate a giant GdbSyms.dll file to import in a single go,
>>>>> but I haven't succeeded at this). This is further complicated
>>>>> that it appears we're asserting somewhere in a driver, and
>>>>> short of adding printfs to *every* driver, its impossible to
>>>>> know which is asseting.
>>>>
>>>> Maybe it's worth adding a hack-support-gdb-in-kvm
>>>> implementation for this. If we go down this road, I can
>>>> probably find time to help you out there.
>>>>
>>>> Can you do some scripting to replace assert statements with "{
>>>> print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }" type
>>>> hack?
>>>>
>>>
>>> That's probably a decent idea if I can find where ASSERT() is
>>> defined. I'll try that in a bit.
>>>
>>>>>
>>>>> Previous attempts to debug assets shows that EFI does "odd"
>>>>> things to the stack when we hit an exception, making walking
>>>>> it with GDB impossible. I need to figure out what madness EFI
>>>>> does with my SP so I can get the entire stack on an
>>>>> explosion, but this remains at best hopeful thinking.
>>>>
>>>> This sounds very strange - could it be that because you take an
>>>> exception, you use a SP from a different mode and everything
>>>> just messes up?
>>>>
>>>
>>> This could be GDB just being unhappy. I've had issues walking
>>> the stack in KVM in general, but even if I walk the stack by
>>> hand, I don't see a pointer to the next frame when we're in an
>>> exception. To my knowledge, UEFI uses the standard AArch64 C ABI,
>>> but this might be a faulty exception on my part.
>>>
>>>>>
>>>>> Further complicating things is that during EBS, my print
>>>>> debugging goes away. I might just cheat and roll a simple
>>>>> assembly function to bang out messages through serial
>>>>> without calling anything else. Ugly as sin, but this should
>>>>> let me get useful debug output through the EBS framework.
>>>>> Complicating matters is that I need to locate each and all
>>>>> EBS() event functions, which are spread *everywhere* in
>>>>> TianoCore, and then debug them each individually.
>>>>
>>>> I'm a little confused no knowing UEFI, is EBS() not a single
>>>> function and what does it matter that it's called from
>>>> multiple places?
>>>>
>>>
>>> So, drivers and applications can enlist to get notification of
>>> when ExitBootServices are called. This pushes a pointer to a
>>> function into an array when is then iterated through and this
>>> pointer is then called so drivers can unregister themselves from
>>> boot services, etc.
>>>
>>> Complicating the issue is I can't use printf once GetMemoryMap()
>>> is called without breaking EBS() (I think this is a bug in UEFI,
>>> leif, 2 cents?, but I think I can twiddle the serial port
>>> directly without breaking shit.
>>
>> yeah, just writing to the pl011 out should be trivial, or add an
>> hvc temporary hack to KVM, I've done things like that when
>> originally debugging kernel boot under KVM.
>>
>
> Just for the record, hvc?
>
>>>
>>> Having slept on it, its probably easy to print out the pointers
>>> as we go through them, so I can get an idea of whats listening
>>> for EBS and try and narrow down my list of candidates.
>>>
>>
>> yes, add a function that side-steps all the UEFI-weirdness (should
>> be a few lines static function) that can print the pointers of the
>> functions you're calling.
>>
>
> Biggest issue is now binutils doesn't like PE?AArch64 files (addr2line
> and friends don't work) but I think I can muddle through it. There are
> tricks at this point I can use if I have a pointer to get an idea
> where UEFI is.
If you could create a bug in the sourceware bugzilla for this issue
then I'll add it to my list of things to fix.
Cheers,
--
Will Newton
Toolchain Working Group, Linaro
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
