On Thu, Jan 17, 2019 at 02:07:32PM +0000, Peter Maydell wrote: > On Thu, 17 Jan 2019 at 13:44, Michael S. Tsirkin <[email protected]> wrote: > > Oh. I am pretty sure it's endian-ness :( > > > > Any chance you can quickly test the below? > > > > That would be appreciated ... > > > > > > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c > > index 0bf7164590..a506dcbb29 100644 > > --- a/tests/bios-tables-test.c > > +++ b/tests/bios-tables-test.c > > @@ -274,6 +274,7 @@ static GArray *load_expected_aml(test_data *data) > > AcpiSdtTable *sdt; > > GError *error = NULL; > > gboolean ret; > > + gsize aml_len; > > > > GArray *exp_tables = g_array_new(false, true, sizeof(AcpiSdtTable)); > > if (getenv("V")) { > > @@ -307,7 +308,8 @@ try_again: > > fprintf(stderr, "Using expected file '%s'\n", aml_file); > > } > > ret = g_file_get_contents(aml_file, (gchar **)&exp_sdt.aml, > > - (gsize *)&exp_sdt.aml_len, &error); > > + &aml_len, &error); > > + exp_sdt.aml_len = aml_len; > > g_assert(ret); > > g_assert_no_error(error); > > g_assert(exp_sdt.aml); > > > I can test that once I've finished processing the other pullreq > I'm currently testing... That's not so much an endianness issue > as trying to fit a 64-bit value into a 32-bit field, though. > That cast in the code that is fixed here is an indication of > the bug :-) > > thanks > -- PMM
Right but it fits on LE. -- MST
