So let me understand. We know that with an out of the box Ubuntu system, as regular user we cannot attach to a running process with either gdb or gdbserver. On the other hand, nominally we can do either
gdb <program> or gdbserver <comm> <program> but Klement are you saying that due to other considerations, like maybe console, only the gdbserver method is practical? At the end of the day, are gdb and gdbserver running on the same machine? That part is weird for me, I mean, new and different, but at Ericsson we used gdbserver in the common configuration -- on an embedded Power PC -- never had any problems -- but I did read now on Google that some cases especially with IDEs like Eclipse, people have had those performance problems with highly threaded programs. For tracing they have fast trace -- I am not sure if that existed 10 years ago when I was at Ericsson. Is vpp built with that? Burt On Fri, Oct 28, 2016 at 4:24 PM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) <ksek...@cisco.com> 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
