Hi, Vladislav! On Jan 27, Vladislav Vaintroub wrote: > > Hi Serg, > > vc_express is historical, does not exist eanymore. I’m not aware vc ever > existed
I'll remove them both, no problem > I’d propose to only have a few options ( –debugger, --server-debug, > --boot-debug, --client-debug, --manual-debug) , rather than 4-5 options > for each debugger, as per Occam’s razor. that'd be too much re-learning. I am used to --gdb (and I suspect many are). I thought about making --help output shorter by not listing windows debuggers on linux and vice versa. Or even not lising anything that's not installed. I thought it might be good to list, say, --valgrind even if valgrind is not available, so that a user would see that she could install valgrind and use it with mtr. But I don't have a strong opinion about it, I can easily make --help to skip unusable entries, if desired. > A reasonable choice of default debugger can be easily made per > platform (e.g vsjitdebugger preferred to windbg on Windows , and gdb > on anything else preferred to llvm debugger). Then –debugger can be > omitted in most cases. I don't want to open this flame war :) ddd vs gdb vs lldb? It's reasonable to expect that reasonable means different things to different people. I prefer vim and gdb, monty likes xemacs and ddd. My main question for you is can you live with ./mtr --devenv instead of ./mtr --debugger=devenv ? Regards, Sergei VP of MariaDB Server Engineering and [email protected] >> From: Sergei Golubchik >> Sent: Tuesday, 26 January 2021 21:32 >> To: [email protected] >> Subject: [Maria-developers] RFC: incompatible changes to mtr debugging >> flags >> >> Hi, all, >> >> Here's a feature I want to discuss, as it's rather incompatibly removes >> a bunch of mtr command-line options. >> >> It's a unified handling of all debuggers. >> >> I wanted to do it for quite a while, but the actual trigger was me >> trying to add support for --rr (https://rr-project.org/) in embedded. >> It was supported only for non-embedded server, and making it work for >> embedded needed way more copy-pasting than I was comfortable with. >> >> So, in my branch all debuggers are not haphazardly added using whatever >> syntax one thought of at the moment and copy-pasted all over. >> They've handled by a common module, all support the same set of options >> (using gdb as an example): --gdb, --boot-gdb, --client-gdb, >> --manual-gdb. Both --gdb and --client-gdb work for embedded. >> All four of them accept an optional argument that can be a semicolon >> separated list of gdb commands, like in >> >> ./mtr 1st --gdb='b mysql_parse;r' >> >> but can start from command-line options too: >> >> ./mtr 1st --boot-gdb='-nh -q;b mysql_parse;r' >> >> A "debugger" is anything that wraps mysqld or mysqltest execution, >> the current list of debuggers is: gdb, ddd, dbx, lldb, valgrind, strace, >> ktrace, rr, devenv, windbg, vc_express, vc, vsjitdebugger. There's also >> "valgdb" that does what '--valgrind --gdb' was doing before. >> >> This removes the following mtr options: --rr-args --rr-dir >> --manual-debug --debugger --strace-option --stracer --valgrind-all >> --valgrind-mysqltest --valgrind-mysqld --valgrind-options >> --valgrind-option --valgrind-path --callgrind, and --valgrind only >> enables it for the server, not for everything. >> >> If pushed, it'll definitely break backward compatibility. But I don't >> think mtr backward compatibility is all that important, it might only >> affect a handful of developers who use scripts to start mtr with specific >> hard-coded settings, those scripts could be easily adjusted. >> It's much more important to have same mtr features in all branches, so >> that when switching between branches, one wouldn't need to guess what >> command line options mtr supports now. That is, if pushed, this should >> go into 10.2. >> >> Opinions? Missing features? Push / not push? >> for the reference, it's in bb-10.2-serg branch at the moment. >> >> Regards, >> Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
