Community
Participate
Working Groups
Build Identifier: I've tried this: f.createMIGDBSet(ctx, new String[]{"backtrace limit", "100"} where the result is queued with IGDBControl. As result, DSF sends: -gdb-set "backtrace limit" 100 And to the best of my knowledge, no version of GDB accepts this, because "gdb-set" is not a "real" MI command. Instead, DSF should use: -gdb-set backtrace limit 100 without any quotes. Reproducible: Always
I don't understand the impacts of "gdb-set is not a real MI command", on quoting, but there should be a way to fix that for the MIGDBSet class. Temporarily, you could also try f.createMIGDBSet(ctx, new String[]{"backtrace","limit", "100"}
I have experienced the same problem with set trace-notes gdb command. Once you use spaces in notes MI sends quoted command -gdb-set trace-notes "some notes with spaces" and then trace-status returns start-notes="\"some notes with spaces\"" which require workaround in Trace Control View. See gerrit for patch: https://git.eclipse.org/r/#/c/8004/
I wonder about some -gdb-set commands and quotes. 1- What about when a directory has a space in it? Do we want to send: -gdb-set solib-search-path /home/marc/my dir/test or -gdb-set solib-search-path "/home/marc/my dir/test" 2- what about arguments to the inferior that have spaces? We surely need: -gdb-set --thread-group i1 args firstArg "second arg" In this #2 case though, the user would have to input the double-quotes themselves to indicate that the two words are a single argument. So maybe it is up to DSF-GDB to retain those quotes. But then we should not escape those quotes, which currently I believe we would do, so it will require some changes. Maybe a safer solution to the problem of -gdb-set trace-notes "some notes with spaces" is to turn off quoting directly in MIGDBSetTraceNote as we do in MIBreakCondition. That way, we don't impact other commands. WDYT?
Marc, in the first case, you shall not use quotes. If you use, they become part of the value, and nothing will work. in the second case, the entire args string should be passed unmodified as provided by user, no quoting either. The point is -gdb-set does not perform MI quote processing, so any such quoting is wrong. Also, this is actually not a new patch; we had it in our product for at least a year, and did not run into issues.
(In reply to comment #4) > Marc, > > in the first case, you shall not use quotes. If you use, they become part of > the value, and nothing will work. Ok, that makes sense. > in the second case, the entire args string should be passed unmodified as > provided by user, no quoting either. I don't think that's what's happening. If you try this program: int main(int argc, char **argv) { for (int i = 0; i < argc; ++i) { printf("arg %d is is: %s\n", i, argv[i]); } return 0; } and in the launch, in the Arguments tab, you put the following line: firstArg "second arg" third\ arg the output I get (with the proposed patch) is: arg 0 is is: /home/lmckhou/runtime-TestDSF/DSFTestApp/Debug/DSFTestApp arg 1 is is: firstArg arg 2 is is: second arg 3 is is: arg arg 4 is is: third arg 5 is is: arg which is wrong, while before the patch I get: arg 0 is is: /home/lmckhou/runtime-TestDSF/DSFTestApp/Debug/DSFTestApp arg 1 is is: firstArg arg 2 is is: second arg arg 3 is is: third arg Which is right, although it illustrates another possible problem where the third\ arg works because we quote it, but we don't keep the \. Actually, we don't keep the original quotes either, but happen to put in our own. This should probably all be fixed. The actual gdb command is: -gdb-set --thread-group i1 args firstArg "second arg" "third arg" > The point is -gdb-set does not perform MI quote processing, so any such > quoting is wrong. Also, this is actually not a new patch; we had it in our > product for at least a year, and did not run into issues. Do you have another patch maybe that handles this args case?
Hi Marc, I have uploaded new patch due my poor knowledge of egit, which uploaded everything what I have locally. This patch is a just cosmetics, doesn't answer your question about gdb-set usage. Don't waste your time on it.
Created attachment 223625 [details] Proposed patch Hi Marc, I'm unable to feed in the new patch into gerrit because of gerrit issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=393735, attaching it here. Thank you for catching problem with previous patch.
(In reply to comment #7) > Created attachment 223625 [details] > Proposed patch > > Hi Marc, I'm unable to feed in the new patch into gerrit because of gerrit > issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=393735, > attaching it here. Thank you for catching problem with previous patch. Thanks. The change seems to fix the problem. I've pushed the new version to Gerrit for you. I'll comment there.
I found that soem JUnit tests broke with this change because we don't handle \n properly anymore. Comments are in Gerrit.
As can be seen from the Gerrit fix, this quoting problem affects -target-select as well. For example: (gdb) -target-select core "Core File" ^error,msg="/home/lmckhou/\"Core File\": No such file or directory." (gdb) -target-select core "/home/lmckhou/Core File" ^error,msg="/home/lmckhou/\"/home/lmckhou/Core File\": No such file or directory." (gdb) -target-select core Core File ^connected,... Same for "-target-select tfile"
