Re: Insight and mingw GUI-programs

Re: Insight and mingw GUI-programs

[Zbynek Winkler]

Hello, I am writing in response to 
http://sources.redhat.com/ml/insight/2004-q1/msg00078.html, because I am 
experiencing the same problem - cygwin version of insight cannot find 
source to a binary compiled with mingw. GDB finds the debug info and the 
output of "tk gdb_loc main" is "../util/test.cpp main ../util/test.cpp 
13 0x0040ad9f 0x0040ad9f {}" which is not where the source is located. 
When I move the binary to a location that corresponds with the above 
findings the source is found. The output of the "tk gdb_loc main" is now 
"../util/test.cpp main /cygdrive/d/ester/util/test.cpp 13 0x0040ad9f 
0x0040ad9f {}".
Zbynek

-- 
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic

Re: Insight and mingw GUI-programs

[Keith Seitz]

On Mon, 2004-05-03 at 12:39, Zbynek Winkler wrote:
> Hello, I am writing in response to 
> http://sources.redhat.com/ml/insight/2004-q1/msg00078.html, because I am 
> experiencing the same problem - cygwin version of insight cannot find 
> source to a binary compiled with mingw. GDB finds the debug info and the 
> output of "tk gdb_loc main" is "../util/test.cpp main ../util/test.cpp 
> 13 0x0040ad9f 0x0040ad9f {}" which is not where the source is located.

What does "info func main" give (type in the console window)? If it is
not correct, you are experiencing a problem with gdb or with the
compiler.

Where is the source located if not in ../util/test.cpp?

Keith

Re: Insight and mingw GUI-programs

[Zbynek Winkler]

Keith Seitz wrote:

>On Mon, 2004-05-03 at 12:39, Zbynek Winkler wrote:
>  
>
>>Hello, I am writing in response to 
>>http://sources.redhat.com/ml/insight/2004-q1/msg00078.html, because I am 
>>experiencing the same problem - cygwin version of insight cannot find 
>>source to a binary compiled with mingw. GDB finds the debug info and the 
>>output of "tk gdb_loc main" is "../util/test.cpp main ../util/test.cpp 
>>13 0x0040ad9f 0x0040ad9f {}" which is not where the source is located.
>>    
>>
>
>What does "info func main" give (type in the console window)? 
>
It is at the end of the email.

>If it is not correct, you are experiencing a problem with gdb or with the
>compiler.
>  
>
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:".

>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?

Zbynek

(gdb) info func main
All functions matching regular expression "main":

File controller/EsterSimul.cpp:
int EsterSimul::main();

File util/Thread.cpp:
int Main::main();

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

File controller/MoveTest.cpp:
int Monitor::main();
int move::Async<num::AngleT<num::Double> >::main();
int move::Async<num::Dist>::main();

Non-debugging symbols:
0x00000000  _ZNSt12domain_errorD0Ev
0x00000000  _ZNSt12domain_errorD1Ev
0x00401000  _mingw32_init_mainargs
0x00401240  mainCRTStartup
0x5a04f31b  RtlEqualDomainName
0x5a04f31b  ntdll!RtlEqualDomainName
0x6fbc13f0  __main
0x77c1ee40  _wgetmainargs
0x77c1ee40  msvcrt!__wgetmainargs
0x77c34f06  _getmainargs
0x77c34f06  msvcrt!__getmainargs


-- 
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic

Re: Insight and mingw GUI-programs

[Keith Seitz]

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

Re: Insight and mingw GUI-programs

[Zbynek Winkler]

Keith Seitz wrote:

>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.
>  
>
I've used "nm -al my.exe" and it seems to have it right but paths are 
windows-like = they start with a letter designating the drive. Could 
this confuse insight/gdb built for cygwin?

Another thing is that when I use mingw version of gdb (5.2.1) and issue 
"info func main" it just crashes (the cygwin version of gdb is fine in 
this case but finds wrong paths). I guess I'll report the crash to mingw 
people...

>I suspect you may simply need to set up a few paths for gdb ("help dir"
>in the console), 
>
I've looked into this and it seems to work. Actually starting insight 
from the root directory of my project as $cwd makes it find the sources 
so I guess I just live with that. I didn't realize that the working 
directory of gdb would have so much effect :(

>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).
>  
>
I am a bit stressed for time now, but I might ask later about this issue 
(I already have a list of things to ask about the tools I use, but it 
has to wait 3 more weeks :().

Thanks for your help.

Zbynek

-- 
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic

Re: Insight and mingw GUI-programs

[keiths]

Quoting "A. Klingenstein" <klingens@web.de>:

> I compiled Inisight 6.0 and 5.3 (todays CVS errored on compile in the 
> UI) with the latest cygwin.
> Now I want to debug a graphical Windows program compiled with Dev-C++ 
> which uses mingw, but Insight won't find the debug info and will display
> 
> only asm, no source. Function names it knows tho. If I try a console 
> program, everything works alright

If insight cannot find source code, it almost certainly means that your
executable was not compiled with debug info. Make sure "-g" is passed to your
executable.

You can double-check this in insight by opening a console window and typing, e.g.
"info func main" (substitute for any function other than main if you like).

If gdb finds symbols for it, I would then try using "tk gdb_loc main" (or
whatever function). This is the function that insight uses to locate source
locations. What does it say?

Keith 

Insight and mingw GUI-programs

[A. Klingenstein]

I compiled Inisight 6.0 and 5.3 (todays CVS errored on compile in the 
UI) with the latest cygwin.
Now I want to debug a graphical Windows program compiled with Dev-C++ 
which uses mingw, but Insight won't find the debug info and will display 
only asm, no source. Function names it knows tho. If I try a console 
program, everything works alright
There seems to be a 2nd bug that when asm is shown, single step or 
breakpoints won't work: the program just runs through. Together those 
two bugs make it impossible to debug a graphical program in any way.
Is this a known error or am I unique? Is there perhaps a fix somewhere?

Alex