Hi all, regarding the discussed changes, here's a patch:
https://gerrit.fd.io/r/#/c/3641/ please do check out: make test-help to get a list of knobs to turn with a brief explanation. I got rid of all the different one-letter switches (kept only the familiar V=<loglevel>) plus added a stepping feature requested by Neale. Regards, Klement On Fri, Oct 28, 2016 at 08:24:45PM +0000, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hi Dave, > > I completely agree with you regarding the gdb server pains. I remember > the horrible IOS-XR gdb server experience, like 'step' taking 10 > seconds, breakpoints not working randomly and so. > > But - on x86[_64] I think it's usable. And I think that this is the main > selling point. The 'make test' is meant mainly as a developer tool. Make > writing unit tests easy and fun and developers will write them even if > they don't have to because it saves them time and having to repeat mundane > tasks. > E.g. now that I'm working on the BFD - it's actually much more faster > to use the python with scapy for repeated test runs as compared to say > setting up a nexus to be the bfd peer and (re)spawning vpp after each crash, > configuring it again etc. This way I just punch a magic button and voila, > the test case does this all for me. Added bonus - we get unit tests. > > There is no need to run the UT framework as root. Actually, that was one > of the first things I did (remove the sudo mess). But on default ubuntu, > this means that you either need to make some system changes or you need > to run gdb as root. > > Regarding dependencies - you can live in your own sandbox. Think > --prefix or so. That's how I actually got a usable vim (on aurora). > And clang - after building my own libc and gcc of course. Etc. > It's pain, but one-time pain and it can be done if you have the willpower. > Or if you don't have any other way :-) > > So - let's keep both options - it's not that much code and lets everybody > use what they like. > > Thanks, > Klement > > On Fri, Oct 28, 2016 at 09:34:02PM +0200, Dave Barach (dbarach) wrote: > > Dear Klement, > > > > > > > > The G=1 story works for me, that’d be fine. > > > > > > > > I hate gdbserver based on years’ worth of experience. Here’s problem 1: > > run gdb + gdbserver on ppc64-be, aarch64-le and so forth. If it's your > > lucky day, it will just about work on one CPU architecture other than > > x86_84. Mix in a half-baked experimental vendor tool chain, and I can all > > but guarantee that your mileage will vary. > > > > > > > > Problem 2: performance, especially when using stream sockets [TCP] > > instead > > of Unix domain sockets. > > > > > > > > Why is it necessary for the UT framework to run vpp-lite as root? I run > > vpp-lite images as uid=1000 all the time. Let’s see if we can figure out > > how to avoid running as root... > > > > > > > > Segway into developers using systems without root access: how could that > > work? Someone stuck in that situation wouldn’t be able to install build > > dependencies and build an image; forget all about the unit test > > framework. > > > > > > > > Aurora systems [a Cisco IT internal PAAS offering] are more or less > > unusable for any kind of vpp work. Cisco IT is not going to let you > > install anything. > > > > > > > > Thanks… Dave > > > > > > > > -----Original Message----- > > From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) > > Sent: Friday, October 28, 2016 1:59 PM > > To: Dave Barach (dbarach) <dbar...@cisco.com> > > Cc: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) > > <jgel...@cisco.com>; vpp-dev@lists.fd.io; csit-...@lists.fd.io > > Subject: Re: [vpp-dev] L2BD test failing during MAC learning - VPP-518 > > > > > > > > Hi Dave, > > > > > > > > the reason why I went the gdbserver way is this: > > > > > > > > Attaching to program: > > > > /home/ksekera/vpp/build-root/install-vpp_lite_debug-native/vpp/bin/vpp, > > > > process 7101 > > > > Could not attach to process. If your uid matches the uid of the target > > > > process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try > > > > again as the root user. For more details, see > > > > /etc/sysctl.d/10-ptrace.conf > > > > ptrace: Operation not permitted. > > > > > > > > I know this can be tuned, but I wanted it to be as user friendly as > > > > possible. One might need to work on a machine where one doesn't have > > > > sudo rights (like the aurora boxes). > > > > > > > > I agree with the sucking part re gdb server, but so far it worked fine > > > > for me. It's just a different line to copy-paste. The only drawback I > > > > see with the gdbserver is the need to check for user stupidity in case > > > > the user just hints enter blindly, while VPP is stuck in gdb server - but > > I've > > > > added a warning for that case so that's done. > > > > > > > > Do you know of any other reasons for not using gdb server? > > > > > > > > Otherwise the flow is the same as you describe - wait for ENTER and run > > the > > > > testcase. > > > > > > > > Now that I think about it, we can have both, S=1 for server, G=1 for > > > > just waiting for the user to attach the gdb if you want. > > > > > > > > Maybe even give it more descriptive names? > > > > > > > > Thanks, > > > > Klement > > > > > > > > On Fri, Oct 28, 2016 at 07:26:34PM +0200, Dave Barach (dbarach) wrote: > > > > > Dear Klement, > > > > > > > > > > > > > > > > > > > > Debugging w/ coredumps is just about worth supporting. I won't use > > it, but > > > > > someone else might. Personally, I'd forget it. > > > > > > > > > > > > > > > > > > > > Debugging w/ gdbserver is a total fail. No need to support it. > > Gdbserver > > > > > sucks. > > > > > > > > > > > > > > > > > > > > What I'm doing right now which is simple and effective: after > > starting > > > > > vpp, but before doing anything: print the vpp pid, and [in the > > cave-man > > > > > dbarach hack version] sleep for a while. In the non-caveman version, > > wait > > > > > until the user types "<return>". > > > > > > > > > > > > > > > > > > > > Meanwhile, in another window: start gdb + emacs on the vpp-lite > > > > > executable. Once the vpp pid is obvious: type "(gdb) attach <pid>". > > Set > > > > > breakpoints as desired, then type "continue". > > > > > > > > > > > > > > > > > > > > That's the slick / adult way to debug vpp. > > > > > > > > > > > > > > > > > > > > By the way, the L2BD test failure seems related to using the same > > mac > > > > > address on multiple interfaces. That’s prima facie illegal. Please > > don’t > > > > > do that. > > > > > > > > > > > > > > > > > > > > I see the code add these 4 raw keys to the l2 FIB: > > > > > > > > > > > > > > > > > > > > 2: /x key0.raw = 0x101ff0000000001 > > > > > > > > > > 2: /x key0.raw = 0x201ff0000000001 > > > > > > > > > > 2: /x key0.raw = 0x301ff0000000001 > > > > > > > > > > 2: /x key0.raw = 0x401ff0000000001 > > > > > > > > > > > > > > > > > > > > Take the mild assumption that these numbers hash to values which > > won’t > > > > > differ in low-order bits. Contestant #5 comes along, and runs the > > hash > > > > > table out of memory trying to pry these entries apart. I’ll go make > > sure > > > > > that I’m right - after lunch - but I’d STRONGLY suggest trying > > different > > > > > MAC addresses if you want the test to pass instantaneously... > > > > > > > > > > > > > > > > > > > > Thanks… Dave > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) > > > > > Sent: Friday, October 28, 2016 12:47 PM > > > > > To: Dave Barach (dbarach) <[1]dbar...@cisco.com> > > > > > Cc: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) > > > > > <[2]jgel...@cisco.com>; [3]vpp-dev@lists.fd.io; > > [4]csit-...@lists.fd.io > > > > > Subject: Re: [vpp-dev] L2BD test failing during MAC learning - > > VPP-518 > > > > > > > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > > > > > > > 2 options: > > > > > > > > > > > > > > > > > > > > 1.) if you set ulimit -c properly and do a make test-debug I=1 > > TEST=l2bd > > > > > > > > > > (or just make test-debug I=1), the test framework should detect the > > > > > > > > > > core, fire up a gdb, load it and give you control (I stands for > > > > > > > > > > "interactive" here) > > > > > > > > > > > > > > > > > > > > 2.) this one is not committed yet, but I have a patch which adds S=1 > > for > > > > > > > > > > running in gdbserver from the start - so at the beginning of each > > test > > > > > > > > > > case, it starts the vpp in gdbserver, prints the command line to > > attach > > > > > > > > > > gdb and waits for an <ENTER> so that you can set breakpoints etc.. I > > > > > > > > > > hope to push this to gerrit soon... > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Klement > > > > > > > > > > > > > > > > > > > > On Fri, Oct 28, 2016 at 04:17:48PM +0000, Dave Barach (dbarach) > > wrote: > > > > > > > > > > > Dear Jan, > > > > > > > > > > > > > > > > > > > > > > This looks for all the world like a bounded-index extensible hash > > > > > jackpot. If that's so, the fix is obvious but it will take a bit of > > time > > > > > to code and test. > > > > > > > > > > > > > > > > > > > > > > Before I go there, I'll need to blow it up myself and poke around > > in > > > > > gdb. Have folks implemented the scheme I asked for - to pause > > test(s) > > so a > > > > > developer can attach to vpp from gdb - before anything else happens? > > > > > > > > > > > > > > > > > > > > > > If not, I can stick a sleep into the test BUT that feature request > > is > > > > > very important. > > > > > > > > > > > > > > > > > > > > > > Thanks... Dave > > > > > > > > > > > > > > > > > > > > > > From: [1][5]vpp-dev-boun...@lists.fd.io > > > > > [[2][6]mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jan Gelety > > -X > > > > > (jgelety - PANTHEON TECHNOLOGIES at Cisco) > > > > > > > > > > > Sent: Friday, October 28, 2016 12:02 PM > > > > > > > > > > > To: [3][7]vpp-dev@lists.fd.io > > > > > > > > > > > Cc: [4][8]csit-...@lists.fd.io > > > > > > > > > > > Subject: [vpp-dev] L2BD test failing during MAC learning - VPP-518 > > > > > > > > > > > > > > > > > > > > > > Dear vpp developers, > > > > > > > > > > > > > > > > > > > > > > We found out that VPP crashes during the MAC learning when run > > L2BD > > test > > > > > that is part of the test framework. The issue is reported here: > > > > > [5][9]https://jira.fd.io/browse/VPP-518 > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > vpp-dev mailing list > > > > > > > > > > > [6][10]vpp-dev@lists.fd.io > > > > > > > > > > > [7][11]https://lists.fd.io/mailman/listinfo/vpp-dev > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. [12]mailto:vpp-dev-boun...@lists.fd.io > > > > > 2. [13]mailto:vpp-dev-boun...@lists.fd.io > > > > > 3. [14]mailto:vpp-dev@lists.fd.io > > > > > 4. [15]mailto:csit-...@lists.fd.io > > > > > 5. [16]https://jira.fd.io/browse/VPP-518 > > > > > 6. [17]mailto:vpp-dev@lists.fd.io > > > > > 7. [18]https://lists.fd.io/mailman/listinfo/vpp-dev > > > > References > > > > Visible links > > 1. mailto:dbar...@cisco.com > > 2. mailto:jgel...@cisco.com > > 3. mailto:vpp-dev@lists.fd.io > > 4. mailto:csit-...@lists.fd.io > > 5. mailto:vpp-dev-boun...@lists.fd.io > > 6. mailto:vpp-dev-boun...@lists.fd.io > > 7. mailto:vpp-dev@lists.fd.io > > 8. mailto:csit-...@lists.fd.io > > 9. https://jira.fd.io/browse/VPP-518 > > 10. mailto:vpp-dev@lists.fd.io > > 11. https://lists.fd.io/mailman/listinfo/vpp-dev > > 12. mailto:vpp-dev-boun...@lists.fd.io > > 13. mailto:vpp-dev-boun...@lists.fd.io > > 14. mailto:vpp-dev@lists.fd.io > > 15. mailto:csit-...@lists.fd.io > > 16. https://jira.fd.io/browse/VPP-518 > > 17. mailto:vpp-dev@lists.fd.io > > 18. https://lists.fd.io/mailman/listinfo/vpp-dev > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
