Hi Sergei! Just tested this out. I like the changes and can live with what you proposed. However, I don't see a reason to get rid of "--manual-debug". I like being able to see what command line parameters are needed to start the server with the exact same setup. Sometimes I use it to start the server manually, with/without the debugger.
Vicențiu On Wed, 27 Jan 2021 at 14:40, Vladislav Vaintroub <vvaintr...@gmail.com> wrote: > > > Hi Serg, > > > > vc_express is historical, does not exist eanymore. I’m not aware vc ever > existed > > > > 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. > > > > 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. > > > > *From: *Sergei Golubchik <s...@mariadb.org> > *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 > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~maria-developers > > Post to : maria-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~maria-developers > > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-developers > Post to : maria-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
