|Re: [dsdp-dd-dev] Source lookup and remote debugging launch sequence|
Daniel Jacobowitz wrote:
That's right, this rings a bell :-). I think the best place to handle this escaping of back slashes would be in the MIBreakInsert constructor, and in any other constructor that deals with file paths.On Wed, Feb 20, 2008 at 01:50:23PM +0100, Tobias Södergren XT wrote:-file-exec-and-symbols C:\\dev\\workspace\\GDB-test\\Threads ^doneFYI, this quoting is correct according to the GDB manual...
Thus the reason why GDB-CDI uses a command factory instead of command constructors directly. In DSF we did away with the command factory, so our debugger will be only compatible with the latest version of the MI protocol. To support older versions of GDB we will need customized services which use old versions of commands.(gdb) -gdb-set sysroot C:\Program\CodeSourcery\SourceryG++\arm-none-linux-gnueabi\libc ^done... and this is correct in practice, but wrong according to the manual. It's a known bug in GDB that we quote different MI commands differently, and I hope we'll fix it eventually.
Hopefully we can handle these differences using appropriate source containers. If that's not enough, we'll need customized GDB-DSF services for these different GDB variants. This is OK, this is how DSF debuggers are meant to be extended.1. It looks loke the gdb MI interface for CodeSourcery accepts inserting breakpoints using backslashGCC puts whatever was on its command line into the ELF file, and GDB reads it from there. So it depends which slashes your builder uses, whether you have a mingw32 or cygwin GCC, et cetera.
I'm not sure output to -break-insert will be that useful, since to insert a breakpoint we need to know the correct path in the first place. But I assume that -stack-list-frames and -file-list-exec-source-files will return correct full paths to use with the path mapping.2. There's a file and a fullname attribute in the response for the -break-insert command, possibly useful for source lookup.Yes indeed.
Back to the top