maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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@xxxxxxxxxxx

>> From: Sergei Golubchik
>> Sent: Tuesday, 26 January 2021 21:32
>> To: maria-developers@xxxxxxxxxxxxxxxxxxx
>> 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