[gem5-dev] Re: version of pybind11 without everything in the headers
Gabe, Following a long chain of links from those patches should eventually lead to: https://github.com/pybind/pybind11/pull/2445 passing through https://gem5.atlassian.net/browse/GEM5-572 The current status is: upstream has said they will merge my split patch at some point. But since it conflicts with everything, they are waiting for a good moment to do that when their major patches get all merged. Then when tell me to rebase, I'll rebase and they will merge immediately, and then I'll send a patch into gem5 updating pybind11 and updating the build system to take advantage of it. I've been pinging them on major Western holidays :-) From: Giacomo Travaglini Sent: Thursday, February 4, 2021 12:01 PM To: gem5 Developer List ; Ciro Santilli Cc: Gabe Black Subject: RE: [gem5-dev] version of pybind11 without everything in the headers Hi Gabe, I believe you are referring to the following ticket: https://gem5.atlassian.net/browse/GEM5-277 Ciro is currently on vacation and he will be back next week so he will be able to update you on his progresses. IIRC pybind folks are reviewing his contribution but I cannot provide you a timeline (Ciro might) Kind Regards Giacomo > -Original Message- > From: Gabe Black via gem5-dev > Sent: 04 February 2021 09:45 > To: gem5 Developer List ; Ciro Santilli > > Cc: Gabe Black > Subject: [gem5-dev] version of pybind11 without everything in the headers > > Hey folks and particularly Ciro, I know a while ago there was an attempt to > put > the common contents of pybind11 into a lib. Did that go anywhere? That > would reduce build time which would be valuable, but from this change it's > apparent that all those common symbols are *really* blowing up the build > directory. > > https://gem5-review.googlesource.com/c/public/gem5/+/40621/1 > > > Gabe ___ 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
[gem5-dev] Status of Compiler-Checks tests
Hi all, We noticed that a recent change https://gem5-review.googlesource.com/c/public/gem5/+/35856 broke the Build on GCC 5.4: build/ARM/dev/reg_bank.test.cc:29:32: error: unknown option after '#pragma GCC diagnostic' kind [-Werror=pragmas] #pragma GCC diagnostic ignored "-Wdeprecated-copy" ^ cc1plus: all warnings being treated as errors The option was apparently only added to GCC 9: https://gcc.gnu.org/gcc-9/changes.html I then searched a bit and found out about Compiler-Checks under http://jenkins.gem5.org/ which is awesome, but unfortunately hasn't passed in a month and not run in 12 days. So I wanted to check what's the status of that setup? That is a very good way to prevent this kind of build break. Even more awesome would be if we could add a build with the minimum supported GCC version to precommits. Let me know if there's anything I can do to help to get that up and running. ___ 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
[gem5-dev] Re: ARM full system boot that uses the HDLCD?
Gabe, last time I touched HDLCD a while back, it worked on fs.py with this setup: https://stackoverflow.com/questions/50364863/how-to-get-graphical-gui-output-and-user-touch-keyboard-mouse-input-in-a-ful/50364864#50364864 I suppose the other main in-tree arm scripts would also work. From: Gabe Black via gem5-dev Sent: Friday, October 30, 2020 1:41 AM To: gem5 Developer List Cc: Gabe Black Subject: [gem5-dev] ARM full system boot that uses the HDLCD? Hey ARM folks. I want to take a look at optimizing the HDLCD framebuffer output, VNC output, etc., since that's a big bottleneck when, for instance, running Fast Model simulation. Is there a simple config I can run without using fast model, etc, which I can use to test the HDLCD and those video features? I'll check how much performance gain there is later on, but for now I just want to make sure I don't break anything. Gabe ___ 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
[gem5-dev] Re: The Nightly Build system is now Live (Compiler tests too!)
Fantastic!!! Which infrastructure does it run on? Google Cloud or something else? From: Bobby Bruce via gem5-dev Sent: Monday, July 27, 2020 7:54 PM To: gem5 Developer List Cc: Bobby Bruce Subject: [gem5-dev] The Nightly Build system is now Live (Compiler tests too!) Dear all, After some tinkering, we now have a nightly build system deployed, run from our Jenkins: https://jenkins.gem5.org. If I've set up the permissions correctly, everyone should be able to see the status of all our builds from there. Please note, at the time of writing, we're still experimenting with other testing/building setups, so there may be builds there that I haven't explained in this email. These can be ignored. Right now, the Nightly Builds compile the NULL, ARM, MIPS, POWER, RISCV, SPARC, and X86 ".opt" variants of gem5, run the unit tests (those executed via `scons build/null/unittests.opt`), and the "long" testlib regression tests (those executed via `scons ./main.py run --length long` from the `tests` directory) on the gem5 develop branch. In order to test that our email provider is functioning correctly, I've set this up to send an email to the gem5-dev mailing list on success or failure, though once I've confirmed the email notifications are working correctly I'll switch this to send on failure only. The nightly builds will execute every day at 11PM PST (6AM UTC). They take around 6 to 7 hours to complete, therefore normally finishing around 6 to 7 AM PST (1PM to 2PM UTC). The email sent on the failure will list the commits included since the last run (in addition to the stdout/stderr logs, and a link to an archive of the `test/.testing-results` directory) which should help us narrow down any cause-of-failure. In addition to the Nightly Builds, there are also Compile Tests, which I've setup to run every Wednesday. These take roughly 24 hours to complete in our current setups, so expect results on Thursdays. The Compiler Tests simply run the `./util/compiler-tests.sh` script on the develop branch. In short, these run all variants of gem5, ".opt" and '.fast", across all major versions of our supported compilers (not a complete cross product, but decent coverage -- please see the script if you want to know exactly what's run). That's pretty much it for now. We've got plans to expand what's tested in the near future: running more tests, more frequently, as well as improve testing for gem5 in general. I hope this email has given a decent overview of what's going on, but please don't hesitate to get in contact with me if you have any questions. I'd also like to take this opportunity to thank Mike Upton for helping us set up the Jenkins server and deal with all the teething problems. His assistance is much appreciated. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net ___ 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
[gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse
I would just use JIRA. But after that, Discourse is the second best. And anything is better than a mailing list :-) From: Jason Lowe-Power via gem5-dev Sent: Tuesday, June 9, 2020 11:40 PM To: gem5 Developer List Cc: gem5 users mailing list ; Jason Lowe-Power Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse +1 for Discourse :). Just to give a bit more context: I'm also trying to find a good forum for community engagement during my online Learning gem5 class this summer. I would like to find a platform that could be used generally for my class this summer, future iterations of the class, and general gem5 questions, as I believe there will be significant overlap between these groups. Other potential options that IMO have more cons than pros when compared to Discourse: - Slack/Teams/etc. - gitter.im - stackoverflow That said, we're open to suggestions :). Our goal is to create the most welcoming and inclusive environment possible. We'll go where our users are! Cheers, Jason On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev wrote: > Dear all, > > In an effort to better support the gem5 community, there has been a > suggestion that we drop the gem5-users mailing list and replace it with > Discourse, https://www.discourse.org/about, a web-based discussion > platform. I'm writing this email to propose this to the community and ask > for feedback on the matter. > > We have noticed that using mailing lists as our primary communication > platform is problematic. Sending an email to a list can be daunting > experience, requiring an etiquette many are not accustom to. I'm sure I'm > not the only one who feels like they are unduly bothering a large number of > people when posting to a list (like I'm doing right now :) ). This is, of > course, an unfortunate hurdle for many to get over when they encounter > problems using gem5, particularly those new to the project. I've come to > believe mailing lists are simply not a very good technology for fostering > community engagement and helping those who are running into difficulties. > Mailing lists are also difficult to search, and lack proper formatting > mechanisms to neatly display attributes such as code and output logs. > > Looking around at alternative technologies available, Discourse appears to > be a suitable replacement. For those unaware, Discourse is (essentially) a > revamp of messaging forums. It is an increasingly popular platform for > users and developers in open source projects to communicate with one > another (see LLVM's discourse as an example: https://llvm.discourse.group > ). > All-in-all, I think it's a well-designed product and contains all the > features we'd expect and need to get our work done. I can see no immediate > downsides to using it, though feedback from the community on the matter > would be greatly appreciated, particularly from those who have used > Discourse before. Dissenting opinions on the whole idea of moving away from > the gem5-user's mailing list are also welcome. > > So, let me know what you think! :) > > Please note, regardless as to any decision made, we will continue the use > of the gem5-dev mailing list for technical discussions for the foreseeable > future. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > > web: https://www.bobbybruce.net > ___ > 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 > ___ 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 ___ 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
[gem5-dev] Re: ISA description structure
Gabe, I just want to say, I would be REALLY happy if those monolithic files were split up somehow, to improve rebuild times and not crash my debuggers/IDEs, if someone manages that it would be amazing. I was also thinking about the scons approach you mentioned, where we can generate one .cc/.hh file for each .isa file separately, so that it would be possible to know what you have to include to avoid having one huge header definition inclusion. I also intend some day to try and reduce the usage of .isa in general, because it is too insane/hard to learn/debug. The decoder part is already basically pure C++ for ARM at least already, so a conversion would be trivial. And I wonder how much we could get rid of with modern C++ template features from the execute itself. From: Gabe Black via gem5-dev Sent: Sunday, May 31, 2020 4:23 AM To: gem5 Developer List Cc: Gabe Black Subject: [gem5-dev] ISA description structure Hi folks. This is just a quick email with some thoughts on the structure of ISA descriptions in gem5, both to record my thinking thus far, and to encourage discussion. Right now, the structure of an ISA description flows from the specification of the decode function. That takes an instruction blob, and then through nested switch statements travels down a decision tree to figure out what the instruction decodes to. At the leaf of the tree, the intention is that an instruction is described inline when and where the decoder should return that instruction. Exactly how that definition is interpreted depends on either an explicit "format" set for that instruction, or a global default format which is active for that region of the decoder. This is relatively straightforward, but makes a few assumptions which, while true for Alpha, are not universally true for all ISAs. 1. That an instruction only shows up in the decoder in one place. 2. That the decoding of an instruction can be expressed as a set of nested switch statements based on bitfields (natural or synthetic) in the canonical ExtMachInst representation of the instruction as pulled from memory. This also doesn't scale very well when there are lots of instructions, or very complex instructions, or lots of very complex instructions, because a lot of the guts of the instructions end up in the decoder itself, rather than pulled into other files. The decoder and instruction header and implementation files end up being HUGE monolithic files which create their own problems, slowing down linking, and even sometimes overwhelming compilers. One thing I'm thinking about is to pull the definition of the instruction objects out of the decoder itself, and to make them their own first class objects. I'm thinking something sort of like SimObjects which have a base class that handles a lot of the magic for them and sets up machinery for outputting .cc and .hh files and specifying how to return one from the decoder. These would then each generate a set of files which would implement just that instruction, and include the headers from any base class, again like SimObjects. Another idea I had more recently is that this could be done at the scons level, so that scons would be aware of all the instructions and the files they generate. This may have an impact on build time and so should be considered carefully. One option would be to tell scons where ISA files were like how Source() files are declared, and then have those do a pre-build but post-source-collection step where they run and expand into .cc and .hh files if they haven't changed. This would be somewhat like how python files are turned into .cc files so they can be embedded into gem5. Thoughts? Gabe ___ 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 ___ 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
[gem5-dev] Re: Debugging application inside gem5 (m5term)
For the gdbserver approach, I haven't found a guest to host networking possibility in gem5 yet: https://stackoverflow.com/questions/48941494/how-to-do-port-forwarding-from-guest-to-host-and-vice-versa-in-gem5 but maybe I missed it. For a non-gdbserver approach, have you tried add-symbol-file as mentioned at https://stackoverflow.com/questions/26271901/is-it-possible-to-use-gdb-and-qemu-to-debug-linux-user-space-programs-and-kernel/46636070#46636070 and https://stackoverflow.com/questions/20380204/how-to-load-multiple-symbol-files-in-gdb BTW, have a look into lx-symbols to help with kernel modules in case you are not using it yet: https://cirosantilli.com/linux-kernel-module-cheat/#gdb-step-debug-kernel-module BTW2 Dealing with userland apps perfectly from gem5 GDB stub (including multiple userland programs with same address) asked at: https://stackoverflow.com/questions/9561546/thread-aware-gdb-for-the-linux-kernel On Tue, May 19, 2020 at 8:03 PM GAURAV JAIN via gem5-dev wrote: > > Hi All, > > We are trying to debug an application running inside gem5 full system. > > After running gem5, we are using 'gdb vmlinux' to attach to it so as to be > able to debug the kernel modules. > > One approach we tried was using the 'file' command to load the symbol table > for the application and continue. But then that approach would overwrite the > existing symbol table (for the kernel modules) with that of the application > which is not what we desire. > > The second approach we tried was running 'gdbserver' inside m5term and then > connect to it through a gdb instance running on the host. > > We did - 'gdbserver localhost:1234 ./app', which seemed to be successful in > launching a process and Listening on the port 1234. > > On the host, we did - 'gdb ./app' and from inside it, 'target remote :1234'. > Doing this did not work and we got the generic error - 'remote:1234 > connection timed out' > > It'd be great if someone could provide pointers on how can we debug an > application running in gem5 full system and if either of the two approaches > mentioned above would work. > > Thanks, > Gaurav > ___ > 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 ___ 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
[gem5-dev] Re: c64 simulation
So this adds a new ISA is that correct? I say add it to the main tree, it could serve as a good small ISA example. Is it running ROMs fine? Is the simulation fast enough for interactive play? Wiki says it run at 1MHz so its just about what Atomic does, so I'm guessing it could. From: Gabe Black via gem5-dev Sent: Monday, May 11, 2020 1:33 AM To: gem5 Developer List Cc: Gabe Black Subject: [gem5-dev] c64 simulation Hi folks. For my own amusement, I've been working on a c64 emulator based on gem5 which can be built in using EXTRAS. Would it make sense to put that up on gerrit somewhere in its own repository? I put what I have so far in a directory called "toys" to make it clear it's just for fun. Gabe ___ 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 ___ 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
[gem5-dev] Patchset to optionally reduce the size of stats.txt
At https://gem5-review.googlesource.com/c/public/gem5/+/28630/1 I have created a patchset to optionally reduce the size of stats.txt by making some simple reductions that users can enable from the command line (namely: remove alignment spaces, dumping only stats under selected SimObject subtrees, and dumping names only on first dump) The reductions are described in detail with examples in the commit messages, and further discussion is present at: https://gem5.atlassian.net/browse/GEM5-508 Jason felt that it would be good to also gather feedback from the dev mailing list since stats are so widely used, so of course, let me know if you have any opinions on this. ___ 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
