Community
Participate
Working Groups
Build Identifier: 20100218-1602 This is CentOS 5.4, x86_64, gdb 6.8-37.el5 I'm trying to debug a C++ project. This is an existing C++ codebase that I edit in Eclipse, but this is the first time I've tried to debug as well. I'm using defaults everywhere. When I try to debug, I see: .gdbinit: No such file or directory. A syntax error in expression, near `-console on'. Clearly the gdb command line is not getting set up correctly. However, gdb does get run despite the problem. Reproducible: Always Steps to Reproduce: 1.Create debug configuration 2. Try to debug 3.
CDT version is: Version: 6.0.2.201002161416 Build id: 201002161416
This is, unfortunately, a known issue with no easy fix. See bug # 288305 Ultimately, as you pointed out, it's harmless, so I don't know how eager anyone is to address it.
(In reply to comment #2) > This is, unfortunately, a known issue with no easy fix. See bug # 288305 > Ultimately, as you pointed out, it's harmless, so I don't know how eager anyone > is to address it. I left a comment in that bug as well, but it seems to me that fixing the common case would still be useful. I.e. it's still worth checking if .gdbinit is missing and don't bother trying to pass it in if so. If nothing else, it will not confuse new users of CDT, leaving them wondering why there are illegal args being fed to gdb. On a related note, is there a way to see the full command being generated?
(In reply to comment #3) > I left a comment in that bug as well, but it seems to me that fixing the common > case would still be useful. I.e. it's still worth checking if .gdbinit is > missing and don't bother trying to pass it in if so. That's the difficulty. How do we know if it's missing? If the user specified an absolute path to the file, that's easy. If it's just a name or a relative path, then it's not so easy. Technically, we shouldn't assume where gdb is going to search when we give it a simple filename or relative path. If you see a workable solution, please submit a patch. > If nothing else, it will not confuse new users of CDT, leaving them wondering > why there are illegal args being fed to gdb. I agree this is not a great situation, but until we have a reasonable way to fix it... > On a related note, is there a way to see the full command being generated? Not that I know of. Would be a nice enhancement if you'd like to contribute :-)
(In reply to comment #4) > (In reply to comment #3) > > I left a comment in that bug as well, but it seems to me that fixing the common > > case would still be useful. I.e. it's still worth checking if .gdbinit is > > missing and don't bother trying to pass it in if so. > > That's the difficulty. How do we know if it's missing? If the user specified an > absolute path to the file, that's easy. If it's just a name or a relative path, > then it's not so easy. Technically, we shouldn't assume where gdb is going to > search when we give it a simple filename or relative path. If you see a > workable solution, please submit a patch. Hmm, my confusion is that when I run gdb from the command line, I don't see any problems like this, i.e. gdb --args myprog arg1. What's different between running gdb from the command line and what eclipse is doing?
(In reply to comment #5) > Hmm, my confusion is that when I run gdb from the command line, I don't see any > problems like this, i.e. gdb --args myprog arg1. What's different between > running gdb from the command line and what eclipse is doing? Eclipse (CDT) is specifying a gdbinit file in all cases, but it doesn't know if it exists or not. That is the crux of the problem. You are not specifying any gdb init file in your cmdline environment, or if you do, you are doing it with a file you know exists. Honestly, the problem is rooted in some bad decisions made a long time ago--the decision to populate a launch configuration with a default value of '.gdbinit'. It should have been left empty and then we'd know not to specify one when we put together the gdb cmdline. And if the user specifies a file in the launch config, then we'd specify it in the cmdline. If gdb reports an error with it, we'd report it to the user. But changing the behavior now is tricky because of the impact to existing users.
I think if we remove it it should not affect existing users much. If they have existing launch configs it would work as before (because it is set) but for new ones we don't specify by default, and relaying on this behavior for "new" configurations is really a corner case.
(In reply to comment #7) > I think if we remove it it should not affect existing users much. > If they have existing launch configs it would work as before (because it > is set) but for new ones we don't specify by default, and relaying on this > behavior for "new" configurations is really a corner case. Good point. At least we can solve the problem for people creating new launch configurations. I'll post something on the mailing list in case there's some use case we're not thinking of (a situation where people rely on that default value).
I think we are doing what we currently do to mimic what GDB does. When GDB is run from the command-line, it automatically sources .gdbinit. So, we want to provide this feature to CDT users, but we also need to allow the user to easily override this, so adding ".gdbinit" as the default value kind of works well. It shows to the user that ".gdbinit" will automatically be loaded, and yet allows for easy overriding. The problem is the error message, which I have to admit has bothered me too. One way to deal with this is that when we launch gdb, we check if we are to source .gdbinit, and if so, we should run gdb _without_ the -nx option. This will have gdb automatically load .gdbinit and not report any error if it doesn't find it. Instead, if the launch specifies any other init file, then we should run gdb with -nx, and explicitely source the file (or maybe run gdb with -x <file> in the case of CDI). I don't really like this solution because, for DSF-DGB, I pursposely kept all GDB command-line option to the strict minimum, so as to make troubleshooting easier. \Having different command-line options in different cases makes things more complex, especially since the command to launch gdb is not printed to our gdbtrace console (we should fix that). For CDI it may not be a problem since command-line arguments are used already. If we can't somehow absorb the error message, then maybe the above is the way to go.
