For reasons I won't bother to get into here, I just fought with using python 3 as the interpreter in gem5, and reran into what I think was this issue:
https://gem5.atlassian.net/browse/GEM5-731 After some digging I found that it was this same issue, so I'm extra motivated for it to be fixed now. I'll put together a new version of your CL which should be good to go. Gabe On Mon, Aug 24, 2020 at 1:47 PM Jason Lowe-Power <[email protected]> wrote: > I finally got back around to this :). > > Here's an updated issue and some WIP changes: > https://gem5.atlassian.net/browse/GEM5-752. I updated our code to work > with current libelf, which was pretty simple except for one change from > 1998 :D. > > There's two things missing: > 1. I'm not sure how to tell scons that libelf is required. I hacked > something up in https://gem5-review.googlesource.com/c/public/gem5/+/33317, > but I know it's wrong. Any pointers on the "right" way to do this would be > appreciated. I couldn't find any other example of *required* libs. > 2. Need to run more tests to double check nothing breaks. > > Cheers, > Jason > > On Tue, Aug 11, 2020 at 7:03 PM Gabe Black <[email protected]> wrote: > >> I see that we had a local version of libelf as far back as when we >> started using scons in 2004, where we referred to it's SConscript in >> m5/libelf/SConscript (not src/m5 or util/m5, just m5), although that >> directory and all its history seems to have been dropped during one of the >> times we switched version control systems I'd guess, probably from >> bitkeeper to mercurial. I think having a local version is a very old >> historical decision, and only someone who was contemporary could tell you >> about it. My guess is to ensure compatibility, probably particular when the >> gem5 binary gets shipped off to another system to actually run. >> >> Gabe >> >> On Tue, Aug 11, 2020 at 6:49 PM Gabe Black <[email protected]> wrote: >> >>> I'm pretty sure it's been that way "forever", where forever is defined >>> as as far back as I can remember. Looking at the history, I see that Nate >>> replaced a GNU libelf with "autoconf nastiness" (I can imagine), and >>> replaced it with a freeBSD version in 2007, so it's been that way at least >>> as long as that. Maybe it was uncommon in package managers, annoying to >>> install, etc? Maybe there were interface differences? I'll see if I can >>> find record of the older GNU version and see if there are any more commit >>> message clues there. I don't *think* we've done anything to customize >>> libelf, but maybe we have or used to. >>> >>> As far as the linker, the short answer is I don't know how it chooses, >>> but I think I've run into that before with some of the fast model stuff. I >>> don't remember all the specifics, but my comment in >>> src/arch/arm/fastmodel/SConscript says: >>> >>> # We need to use the static libraries as files so that the linker >>> # doesn't use the shared versions of them instead. We need to use >>> # the shared libraries by name so that the linker will apply >>> RPATH >>> # and be able to find them at run time. If a shared libary >>> includes >>> # a path, the dynamic linker will apparently ignore RPATH when >>> looking >>> # for it. >>> >>> Or in other words, .../build/ARM/libfoo.a and -lfoo for libfoo.so so we >>> can embed what relative path to find that library at in the binary. >>> >>> Gabe >>> >>> On Tue, Aug 11, 2020 at 6:10 PM Jason Lowe-Power via gem5-dev < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> Does anyone remember why we have our own libelf in ext? Gabe, you were >>>> recently changing the elf loader, do you have any idea? >>>> >>>> I'm having a huge frustration trying to get gem5 to work with openSUSE. >>>> For some reason, gem5 is picking up the libelf.so file in /usr/lib instead >>>> of the libelf.a in build/libelf/. This is causing a segfault in >>>> ElfObject::determineOpSys() because the Elf_Data returned by libelf.so is >>>> in a different format than what our "special" libelf expects. If I force >>>> gem5 to use libelf.a (by manually linking) things work fine. I've also >>>> double checked in gdb that all of the elf calls are going to the libelf.so >>>> in /usr. >>>> >>>> I guess I have two questions: >>>> 1. Why do we ship libelf and not use the generic one? >>>> 2. Why would the linker prefer the shared lib in /lib instead of the >>>> static lib in build/libelf? Does anyone know how to convince the linker to >>>> grab the right one? >>>> >>>> Thanks, >>>> Jason >>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>>
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
