So, I looked into this a little more and tried switching to 5.3. The problem there is subtle, and is that 5.1 puts its headers in their own directory under /usr/include, at least on my system, and 5.3 puts its headers right in the top directory, in /usr/include directly. When you run pkg-config, that gives you a -I on 5.1, but because the headers are in a standard location for 5.3 it does not. The -I effectively makes the cross compilation escape the sysroot of the cross compiler on 5.1 making the build succeed, but for 5.3 the build will only work if 5.3 is actually installed in the sysroot for each system you're building for.
In the case of both the java and lua wrappers, we're assuming that the system headers are compatible with the cross compiler environment which may or may not be true. I think in both cases, as long as system includes and architecture specific macros come from the sysroot then everything should be fine and it will actually work, but it's not completely safe. We've also been getting lucky as far as even being able to find the headers for the reasons above. So again I ask, do we want to keep the lua wrapper? Do we want to port it to 5.3 assuming that we then require it (or really it's headers) to be installed in the sysroot of each cross compiler? Do we get rid of it and sidestep the problem? I personally think it would be nice, with a combination of crosstool-ng and buildroot configs, to make it easy(-ier) for people to both build up a root filesystem to use, and also to build their own custom software for it which may need special headers, etc. That would more or less address this problem, but would be a non-trivial (but not overwhelming) bit of engineering work. Gabe On Fri, Apr 3, 2020 at 4:39 AM Gabe Black <gabebl...@google.com> wrote: > Hi folks. I've been reading up on Lua so that I can implement some testing > for the lua bindings for the m5 ops, and since that seems like more > tractable way to test the PIC version of the m5op code than the java > bindings which would require an image with a JVM in it. > > I was wondering, does the lua binding provide a significant benefit over, > say, the m5 utility itself or the java binding? Is it worth keeping? Or is > it too niche to justify the overhead of maintaining it and testing it > properly? > > Also, lua 5.1 (the version the wrapper uses) represents all numbers as > doubles, including the addresses being passed to the m5 ops. This will > almost certainly cause problems for some ops like arm, init_param, and > add_symbol, and may lead to imprecision in other ops. > > In lua 5.3, I've read that numbers can now be either doubles or long longs > (generally 64 bit according to the manual) which would be able to represent > these values correctly. > > Do we want to switch to 5.3? > > Gabe > > https://www.lua.org/pil/contents.html > > https://stackoverflow.com/questions/3104722/does-lua-make-use-of-64-bit-integers > http://www.lua.org/manual/5.3/manual.html#2.1 > _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
