You could also just file things like that in the corresponding component, and maybe create some kind of meta bug for gdb hooks. So debugging for nsTArray would be filed in XPCOM, etc. I think that's the way it works for Javascript engine related debugging hooks. Failing that, having the nested gdb inside Debugger seems like overkill given that no top level Core::Debugger component exists right now. Maybe if in the future there's a flood of gdb and lldb bugs it would be further subdivided.
On Fri, Sep 16, 2016 at 7:50 AM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > Right now the gecko gdb pretty-printers have been tracked using bugs in > "Core :: Build Config" because that's where the bug that first added them > lived. That component currently has 1773 bugs in it, 3 of which involve > gdb, and with daily activity of ~10 bugs a day. I think a more targeted > component could be useful since gdb users could watch the component without > getting the comparative fire hose of Build Config. Right now notifications > would need to come via explicit CC or watching for changes in dependencies > of the existing bugs. > > The component would presumably cover not just the gdb pretty printers but > also other gdb related issues. > > The triggering factor is that I made a foolish mistake with the > nsTHashtable pretty-printer. It has been telling lies, see > https://bugzilla.mozilla.org/show_bug.cgi?id=1303174 (fix on inbound, > with apologies to anyone misled by the broken pretty-printer). > > Andrew > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
