Re: DxeCore assert during initialization

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 23 February 2017 at 17:51, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/23/17 18:38, Ard Biesheuvel wrote:
>> On 23 February 2017 at 17:33, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 02/23/17 18:29, Laszlo Ersek wrote:
>>>
>>>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.
>>>
>>> Hm, I have some patches in QEMU, so that hash will likely not resolve on
>>> your side. The first upstream ancestor is e295a154c2a9.
>>>
>>
>> Could you please double check?
>>
>> $ git show e295a154c2a9
>> fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
>> in the working tree.
>
> That's the QEMU git hash:
>
> e295a154c2a9 ("Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20170221' into staging", 2017-02-21)
>
> http://git.qemu-project.org/?p=qemu.git;a=commit;h=e295a154c2a9
>
>>
>> In any case, it faults on address 0x1383C6E94 with a data abort due to
>> permissions, which can only be caused by a store to read-only region.
>>
>> This is at the end of the .text segment of UiApp.dll
>>
>> Could you open the .dll in GDB (you may need to do 'set architecture
>> aarch64'), and paste the output of
>>
>> disas *0x3070
>
> I don't have an aarch64 GDB on my laptop, but I have addr2line:
>
> $ aarch64-linux-gnu-addr2line \
>   -e Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.debug \
>   0x3070
> .../MdeModulePkg/Application/UiApp/FrontPage.c:834
>
> This looks reasonable, because the crash hit after I pressed ESC on the splash screen, and was about to get in the menu.
>
>    826    //
>    827    // Set PCD to Inform GraphicsConsole to change video resolution.
>    828    // Set PCD to Inform Consplitter to change text mode.
>    829    //
>    830    Status = PcdSet32S (PcdVideoHorizontalResolution, NewHorizontalResolution);
>    831    ASSERT_EFI_ERROR (Status);
>    832    Status = PcdSet32S (PcdVideoVerticalResolution, NewVerticalResolution);
>    833    ASSERT_EFI_ERROR (Status);
>    834    Status = PcdSet32S (PcdConOutColumn, NewColumns); <---------- here
>    835    ASSERT_EFI_ERROR (Status);
>    836    Status = PcdSet32S (PcdConOutRow, NewRows);
>    837    ASSERT_EFI_ERROR (Status);
>
> Disassembly with objdump:
>
>   Status = PcdSet32S (PcdConOutColumn, NewColumns);
>     3064:       f00001a0        adrp    x0, 3a000 <mHiiDefaultTypeToWidth+0x3968>
>     3068:       913a5000        add     x0, x0, #0xe94
>     306c:       b9407ba1        ldr     w1, [x29,#120]
>     3070:       b9000001        str     w1, [x0]      <--------- here
>     3074:       f90033bf        str     xzr, [x29,#96]
>
> Does this help?
>

Yes, it does.

This bit, from BaseTools/Scripts/GccBase.lds

    /*
     * The contents of AutoGen.c files are constant from the POV of the program,
     * but most of its contents end up in .data or .bss by default since few of
     * the variable definitions that get emitted are declared as CONST.
     */
    *:AutoGen.obj(.data .data.* .bss .bss.*)

turns out to be inaccurate: AutoGen.c also contains (in this case),

.data._gPcd_BinaryPatch_PcdSetupConOutColumn

which is set by the PcdSet32S() call above.

Let me try if I can find a nice fix for this, but simply removing the
line should solve the issue for you.