Re: Insight and mingw GUI-programs

[Keith Seitz <keiths at redhat dot com>]

On Mon, 2004-05-03 at 14:21, Zbynek Winkler wrote:
> It is not correct. It is not even consistent with itself - ie. if there 
> is "File ../util/test.cpp:" for the main, there should be "File 
> ../controller/MoveTest.cpp:" for the others instead of "File 
> controller/MoveTest.cpp:".

Not necessarily. It all depends on your build environment. For example,
if your executable is built something like this:

$ pwd
here
$ cd here
$ cd where
$ make
gcc -BLAH -BLAH foo.cpp bar.cpp baz.cpp -o libfoobarbaz.a
$ cd ..
$ cd there
$ make
gcc -BLAH -BLAH foo1.cpp bar1.cpp baz1.cpp -o libfoobarbaz1.a
$ cd ..
$ gcc -BLAH -BLAH main.cpp where/libfoobarbaz.a there/libfoobarbaz1.a

In this case, gdb could get confused if the compilation directory is not
being properly set by the compiler.

> >Where is the source located if not in ../util/test.cpp?
> >  
> >
> The binary is located at "_build\controller\gcc\debug\arit-double\" and 
> the source is at "util\test.cpp" and "controller\MoveTest.cpp" and 
> others (paths relative to the root of my project). How do I know if it 
> is the compiler or the debugger? Could it be related to the fact that 
> "mingw/bin" directory is in my path? Maybe some version mismatch between 
> cygwin gdb and mingw gdb? How does insight locate the debugger?

>From the output of info func main. This tells you exactly where gdb
thinks everything is located. If "info func" is not returning the
correct location of main(), then either the symbol readers are screwed
up, or the debug info output by the compiler is messed up.

You can use objdump (non-DWARF2) or readelf (DWARF2) to output the
symbols in your executable. If objdump/readelf have it wrong, it is very
likely the compiler that's wrong.

Something tells me, though, that it is neither the compiler nor the
debugger that is wrong. It has always been the case in the past that
situations like your arise from build environments that have confused
gdb.


> File ../util/test.cpp:
> int main(int, char **);
> static void _GLOBAL__D_main(void);
> static void _GLOBAL__I_main(void);

Ugh. I don't like the look of this... When you type "tk gdb_loc main",
does it give the same start address as "p main" or "p
_GLOBAL__D_main(void)"?

To be honest, it has been quite some time since I've chased down bugs
like this. If you can reproduce your problem with only the command line
(i.e., gdb) by listing the source ("list main"), then your best bet is
to ask on the gdb mailing list, since there are far more developers that
hang out on that list than here.

I suspect you may simply need to set up a few paths for gdb ("help dir"
in the console), but just in case you are running into something more
serious, I recommend the fine folks on the gdb mailing list (if you can
get gdb to replicate the error, and it sounds like you can).

Keith