![](https://secure.gravatar.com/avatar/39b623a1559cf9c69ac3d9d4fb44e7fe.jpg?s=120&d=mm&r=g)
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 security@mariadb.org
From: Sergei Golubchik Sent: Tuesday, 26 January 2021 21:32 To: maria-developers@lists.launchpad.net 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