Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)
From: Jeffrey Merkey
Date: Mon Oct 03 2016 - 23:14:28 EST
On 10/3/16, Jeffrey Merkey <jeffmerkey@xxxxxxxxx> wrote:
> On 10/3/16, Joe Perches <joe@xxxxxxxxxxx> wrote:
>> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>>> Hi Joe,
>> Hi Stephen.
>>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches <joe@xxxxxxxxxxx> wrote:
>>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>>> > > The following changes since commit
>>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>>> > >
>>> > > Linux 4.8 (2016-10-02 16:24:33 -0700)
>>> > >
>>> > > are available in the git repository at:
>>> > >
>>> > > https://github.com/jeffmerkey/linux.git mdb-v4.8
>>> > >
>>> > > for you to fetch changes up to
>>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>>> > >
>>> > > Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>>> > Stephen, can this tree be added to -next to get some
>>> > exposure for the next cycle?
>>> I don't add trees during the merge window (unless they contain stuff
>>> for the current merge window and, even then, only rarely). Also, I
>>> only take requests from the maintainer/owner of the tree.
>> No worries, it's really a request for Jeff who doesn't seem
>> to know the process very well.
>> Jeff, you really should get this into -next before sending a
>> pull request to Linus for this large bit of code.
>>> Has there been much recent discussion/review/testing of this tree?
>> Not to my knowledge for about 6 months now.
>>> Is it likely that Linus will merge it? (Just asking, I haven't been
>>> following it.)
>> Dunno. I'd guess it will _not_ be merged without some time
>> in -next and a compelling reason to use it.
> Hi Joe,
> Hi Stephen,
> I put it out as a pull request so the kbuild test robot can build it
> against all sort of configs to make certain it runs across all
> i386/x86_64 configs. If I recall correctly, Ingo Molnar stated he
> would be interested in mdb being chopped up into pieces and possibly
> integrated into kdb, since MDB has a very good disassembler and
> conditional breakpoints which kdb lacks, if I understood what he said
> last linux release when this came up.
> Since I produce mdb for mostly my own internal use, I have not done
> this integration work as of yet as I have been more a user of MDB than
> the developer of late. That's not to say someone else could do what
> Ingo suggested, and I have looked over KDB but to be honest, it would
> require a whole lot of non-intrusive changes to kdb to pull it off --
> not impossible but where I left it with Ingo is he would need to ask
> and be specific about what changes or sections he would want in KDB.
> Without specific guidance from him, I hesitate to work on it -- in
> other words he needs to ask me exactly what he expects to be done
> here. kdb is a very unstable tool from what limited testing I have
> done and it's processor roundup for SMP systems is a very different
> approach from mdb and is prone to crashes and lockups (particularly
> when you are servicing multiple NMI interrupts and more then one of
> the processors ends up in the INT1 exception handler).
> MDB's plus to Linux is a working deferenced disassembler which kdb
> lacks. Ingo did not like the fact the MDB is monolithic if I read
> what he said correctly, and I can see his point, however, debuggers
> are always tightly coupled with the underlying arch. kgdb is
> interesting but is not a standalone debugger, requires two boxes, and
> uses a cumbersome command syntax.
> That being said, Ingo will need to ask me to do the work then be a
> little more forthright about his interest -- if any -- and provide
> some guidance. If Linus wants to pull it be my guest. It's always
> out there for him or anyone else who needs it.
The mdb disassembler also supports multiple disassembly options 16
bit, 32 bit, 64 bit, intel and GNU formats all interchangable with
simple commands which is something even kgdb does not support.