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
