That sounds like a good idea to me, to allow both possibilities. It would be good to have more descriptive names.
I agree gdbserver is harder to use. It does, however, help with the following: 1. The problem of having to run gdb as root, as mentioned by Klement. 2. It lets me do target remote from gdb running on another VM which is the build VM with access to the git repo of source files and the binaries built. Now I can remote debug the binary running on a target VM from the build VM with full access to source files within my gdb session running under emacs. Regards, John -----Original Message----- From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) Sent: Friday, October 28, 2016 1:59 PM To: Dave Barach (dbarach) Cc: csit-...@lists.fd.io; vpp-dev@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) <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, > > > > 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]vpp-dev-boun...@lists.fd.io > [[2]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]vpp-dev@lists.fd.io > > > Cc: [4]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]https://jira.fd.io/browse/VPP-518 > > > > > > Regards, > > > Jan > > > > > > > > _______________________________________________ > > > vpp-dev mailing list > > > [6]vpp-dev@lists.fd.io > > > [7]https://lists.fd.io/mailman/listinfo/vpp-dev > > References > > Visible links > 1. mailto:vpp-dev-boun...@lists.fd.io > 2. mailto:vpp-dev-boun...@lists.fd.io > 3. mailto:vpp-dev@lists.fd.io > 4. mailto:csit-...@lists.fd.io > 5. https://jira.fd.io/browse/VPP-518 > 6. mailto:vpp-dev@lists.fd.io > 7. 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
