MIME-Version: 1.0
In-Reply-To: <836101345823425@web22d.yandex.ru>
References: <CACgPhYro_sDrwyoK_-_VepROj-Q+Fzpgq4Sy0RP7NJjf1f-oAQ AT mail DOT gmail DOT com>	<836101345823425 AT web22d DOT yandex DOT ru>
Date: Fri, 24 Aug 2012 21:55:01 +0400
Message-ID: <CACgPhYqdezbs_fF3WB8sZvTPyR9Ac4BmrOcak_XJGpgp+RpTdw@mail.gmail.com>
Subject: Re: GDB behaves differently on the final cygwin1.dll 1.7.16 and on a previous one.
From: Andrey Khalyavin <halyavin AT google DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit

On 2012/8/24 Evgeny Tarasov wrote:
>
>
> On 24.08.2012, 14:43, "Andrey Khalyavin" wrote:
>> On  Fri, 24 Aug 2012 01:45:11 +0400, Evgeny Tarasov wrote:
>>
>>> Well,
>>>
>>> I've got two different cygwin1.dll's of 1.7.16 version.
>>> The first one was obtained from cvs and built by myself (is it attached to 5th june, 2012; as uname -a says)
>>> The other one is of final 20 july, 2012 ver.
>>>
>>> So my question is the following:
>>> Why the same GDB does not want to put breakpoints to the same (and any) source when I work with the latest of the two.
>>> I always have completely updated cygwin installation, but in order to debug, i have to replace the latest cygwin1.dll with the previous.
>>
>> You need to install Debug/cygwin-debuginfo package. Then you will be
>> able to set breakpoints by line:
>> (gdb) symbol-file cygwin1.dll
>> Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
>> /usr/lib/debug/usr/bin/cygwin1.dbg...done.
>> done.
>> (gdb) b _cygtls::call2
>> Breakpoint 1 at 0x610050e0: file
>> /usr/src/debug/cygwin-1.7.16-1/winsup/cygwin/cygtls.cc, line 92.
>>
>> Andrey Khalyavin
>>
> Hello. It is quite interesting... but could you provide me with step-by-step instructions of how to move further according to the output underneath?
>
> (Single trouble is that I usually use a 3rd party GUI IDE to debug my cygwin code. And this particular IDE (one of its nightly branches), while debugging, sets gdb breakpoints on basis of "mount-like" capabilities of cygwin (i.e. in the form of /cygdrive/disk/cygwin/home/and soon...).
> So, I have 2 ways: either hack the sources of the IDE to adjust working with gdb on a bare filename basis (with no paths), or ask cygwin people to help to debug with "mount-like" filenames. Mount-like breakpoints were workable two month ago.)
>
>
> $ uname -a
> CYGWIN_NT-6.1 evgeny 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin
>
> $ gdb
> GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-cygwin".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> (gdb) pwd
> Working directory /home/evgeny/mip_cb.
> (gdb) file comscan.exe
> Reading symbols from /home/evgeny/mip_cb/comscan.exe...done.
> (gdb) break "/cygdrive/c/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp:346"
> No source file named /cygdrive/c/cygwin/home/evgeny/comscan.cpp.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb) break comscan.cpp:346
> Breakpoint 1 at 0x4043db: file C:/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp, line 346.
> (gdb) cont
> The program is not being run.
> (gdb) run
> Starting program: /home/evgeny/mip_cb/comscan.exe
> [New Thread 424.0xdd4]
> [New Thread 424.0x870]
> [New Thread 424.0x784]
> [New Thread 424.0xb14]
> [New Thread 424.0x270]
>
> Breakpoint 1, main (argc=1, argv=0x22ac50) at C:/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp:346
> 346         w.setWindowTitle("QT-4 ComScan");
> (gdb) list
> 341     {
> 342         QApplication a( argc, argv );
> 343         ComscanWidget w;
> 344         //w.moveToThread(QApplication::instance()->thread());
> 345         w.resize(600, 500 );
> 346         w.setWindowTitle("QT-4 ComScan");
> 347         w.show();
> 348
> 349         return a.exec();
> 350     }
>
>
>
> than I'd  changed cygwin1.dll (to june version) and started cygwin bash shell again
>
> $ uname -a
> CYGWIN_NT-6.1 evgeny 1.7.16(0.261/5/3) 2012-06-05 15:54 i686 Cygwin
>
> $ gdb
> GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-cygwin".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> (gdb) pwd
> Working directory /home/evgeny/mip_cb.
> (gdb) file comscan.exe
> Reading symbols from /home/evgeny/mip_cb/comscan.exe...done.
> (gdb) break "/cygdrive/c/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp:346"
> Breakpoint 1 at 0x4043db: file C:/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp, line 346.
> (gdb) break "comscan.cpp:346"
> Note: breakpoint 1 also set at pc 0x4043db.
> Breakpoint 2 at 0x4043db: file C:/cygwin/home/evgeny/mip_cb/Comscan/comscan.cpp, line 346.
>
> p.s.
> Thus, 2012-06-05 version is fine!
>
> p.p.s
> 2012-07-20 version is also workable at debug, but on a different mount (if executables and its sources are not in the structure of cygwin deploy tree, but on the D disk)

I thought that you have trouble with debugging cygwin1.dll itself.
This problem is mysterious to me.
Wild guess - there is a symlink somewhere in the path and new cygwin
version doesn't recognize it somewhy.
In this case you need to recreate it with new version of cygwin1.dll.

Or you can try to debug gdb with gdb (use "set prompt (gdb2)" to
distinguish between them during debugging).
As far as I understand, it is symtabs_from_filename function in
gdb/linespec.c that produces this error message.
I would check this fact and would try to step into
collect_symtabs_from_filename function to see how it
opens the source file.

You may need to build gdb from sources to get debug symbols for gdb
itself though.

Andrey Khalyavin

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple