https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #25 from Mark Wielaard <m...@klomp.org> --- (In reply to Tom Tromey from comment #22) > (In reply to Paul Floyd from comment #21) > > > I also tried to make the startup even easier and after searching a bit and > > getting some info on SO I came up with > > I don't know the exact problem here -- I don't use "extended-remote" much > if at all The basic difference between target remote and target extended-remote is whether the target can (re)start the program. Basically with target remote gdb connects to an already running/starting program and the target disconnects when the program ends, while with target extended-remote gdb connects to a target that can (re)start a program and keeps connected to the target even after to program ends, so it can restart the program or run another. > -- but we could write a new "target valgrind" command in Python > (shipped with valgrind) that automates some of this. Doing it as a python script is an interesting idea. The next valgrind will ship with some gdb python scripts already. The question is how to auto-load it when gdb starts up. > > eval "set remote exec-file %s", $programname > > Like this bit could be done automatically. > Though it occurs to me that it might be even nicer to give > gdb some mode like "gdbserver but we know it shares the filesystem", > so that "remote exec-file" and "sysroot" aren't needed at all. Yes, that plus a way to share the tty or have stdin/stdout redirected to some alternative file descriptors (currently they are used by the pipe to talk the so you cannot directly get input/output to/from the program) https://sourceware.org/bugzilla/show_bug.cgi?id=28916 > > Again I don't know how to do it, but this gdb function would be nicer if > > there's a way to pass args to the vgdb line to pass on to valgrind. > > I would have thought this was handled by extended-remote? Unless you mean > some kind of valgrind-specific args, not args to the inferior? > > The latter could be done by the putative "target valgrind" easily - it could > parse its own arguments and do whatever it likes. The idea is that any arguments passed to vgdb --vargs .... will be passed to valgrind when it starts up. -- You are receiving this mail because: You are watching all bug changes.
