>>> On 03.09.18 at 16:19, wrote:
> On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
>> >>> On 24.08.18 at 11:58, wrote:
>> > --- /dev/null
>> > +++ b/tools/firmware/hvmloader/hvmloader.lds
>> > @@ -0,0 +1,13 @@
>> > +SECTIONS
>> > +{
>> > + . = 0x10;
>> > + /*
>> > + * NB:
On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
> >>> On 24.08.18 at 11:58, wrote:
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/hvmloader.lds
> > @@ -0,0 +1,13 @@
> > +SECTIONS
> > +{
> > + . = 0x10;
> > + /*
> > + * NB: there's no need to use the AT keyword in order
>>> On 24.08.18 at 11:58, wrote:
> --- /dev/null
> +++ b/tools/firmware/hvmloader/hvmloader.lds
> @@ -0,0 +1,13 @@
> +SECTIONS
> +{
> + . = 0x10;
> + /*
> + * NB: there's no need to use the AT keyword in order to set the LMA, by
> + * default the linker will use VMA = LMA unless
The hvmloader binary generated when using LLVM LD doesn't work
properly and seems to get stuck while trying to generate and load the
ACPI tables. This is caused by the layout of the binary when linked
with LLVM LD.
LLVM LD has a different default linker script that GNU LD, and the
resulting
