On Mon, Apr 11, 2011 at 2:17 PM, André Pönitz <[email protected]> wrote:
> On Monday 11 April 2011 13:56:07 ext Christoph Mathys wrote:
>> Now I wonder about several things:
>> - Is there any clean way of changing the way threadnames behaves?
>> Right now, I just hacked the code in dumper.py. With clean I mean a
>> proper way to distribute this functionality to coworkers.
>
> The obvious way would be to make your changes available upstream,
> after checking they are robust enough for "public consumption".
My code really is not configurable in any way. I haven't started to
think about a general solution. Maybe using some kind of hooks called
to match the name of the stack frame and to retrieve the threads name
from the matched frame? This hooks could be redefined in .gdbinit.
I also think the thread that was selected on entering invoke() should
be selected again when leaving. Something like that:
In ThreadNamesCommand.invoke():
try:
curThread = gdb.selected_thread()
self.searchThreadNames(arg, from_tty)
finally:
if curThread is not None:
curThread.switch()
> Robustness was the reason that code was disabled but not removed,
> so that people have something to start playing with.
What is not 'robust' about it?
> The "GDB startup script" is sourced _after_ dumper.py and gdbmacro.py
> have been read. So that's the location to "fix" whatever was in these
> file before.
I looked again into this. .gdbinit is called too late, qtcreator has
already decided to support threadname or not. And it will always
decide not to, because dumper.py has a hardcoded "return False" in
hasInferiorThreadList(). So, unless I'm missing something, I think
there is no way of not having to hack the original scripts.
Overwriting the threadname command with my own version seems to work
however.
Apparently I also need to call bbsetup after defining a new custom
dumper in .gdbinit. Otherwise, it will not be in the dumper map.
I also noticed that the option "Use debugging helper from custom
location" doesn't do anything, at least not with python scripts. I
tried giving a directory and the filename of a script.
> Perhaps. I found it useful to _not_ let the python code catch exceptions
> in that case, by either commenting out the try...except... bits, or in case
> of the dumpers themselves, pass the 'pe' option to the 'bb' call.
Thanks for the hint. What I found rather useful is to have the custom
dumper read it's code from a file when it is executed. This way, I can
sit on a breakpoint and just doubleclick the stackframe to execute my
changed dumper code. Pattern is something like that:
In the definition file read by gdb during init:
def qdump__XmlNode(d, item):
execfile('/tmp/test.py', globals())
xmlNode(d, item)
in /tmp/test.py:
def xmlNode(d, item):
try:
# dumper code
except Exception as e:
warn(str(e))
Christoph
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-creator
