From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1432 invoked by alias); 24 Jan 2012 14:36:48 -0000 Received: (qmail 1318 invoked by uid 22791); 24 Jan 2012 14:36:47 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_FD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 14:36:30 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OEaGmx006696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 09:36:16 -0500 Received: from host2.jankratochvil.net (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0OEaASs001109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 09:36:13 -0500 Date: Tue, 24 Jan 2012 14:45:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: Pedro Alves , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [patch] Do not open Python scripts twice #2 [Re: [RFC] Crash sourcing Python script on Windows] Message-ID: <20120124143609.GA20367@host2.jankratochvil.net> References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <20120123181125.GA26683@host2.jankratochvil.net> <4F1DA92A.4020207@redhat.com> <20120123210850.GA28792@host2.jankratochvil.net> <20120123221706.GA21051@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00824.txt.bz2 On Mon, 23 Jan 2012 23:47:12 +0100, Doug Evans wrote: > On Mon, Jan 23, 2012 at 2:17 PM, Jan Kratochvil wrote: > > It is the similar reason I disable GDB directories relocation in Fedora - as > > it is not a normal native application behavior - and in some corner cases it > > even breaks execution. > > Huh. Can you elaborate? # ls -l /var/mail/root /var/lib/mock/fedora-15-x86_64/root/var/mail/root -rw------- 1 root root 785 Jan 24 00:08 /var/mail/root -rw------- 1 root root 0 Jan 24 15:06 /var/lib/mock/fedora-15-x86_64/root/var/mail/root # mutt --- The mail (785 bytes) is displayed correctly. # /var/lib/mock/fedora-15-x86_64/root/usr/bin/mutt --- The mail (785 bytes) is also displayed correctly. # gdb mkdir GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) [...] Reading symbols from /bin/mkdir...Reading symbols from /usr/lib/debug/bin/mkdir.debug...done. done. --- GDB works OK # /var/lib/mock/fedora-15-x86_64/root/usr/bin/gdb mkdir GNU gdb (GDB) Fedora (7.3.1-47.fc15) [...] Reading symbols from /bin/mkdir...Missing separate debuginfo for /bin/mkdir Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /var/lib/mock/fedora-15-x86_64/root/usr/lib/debug/.build-id/93/d9b3a3ab008848c7cb73979e6d7a6bb1256e28.debug (no debugging symbols found)...done. --- GDB is broken! Why it reads some weird paths? I just ran the gdb binary. --- These GDB variants here still contain the FSF GDB directory relocations. vvv (gdb) python print gdb.PYTHONDIR /var/lib/mock/fedora-15-x86_64/root/usr/share/gdb/python (gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/var/lib/mock/fedora-15-x86_64/root/usr/lib/debug". # ldd /var/lib/mock/fedora-15-x86_64/root/usr/bin/gdb libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003690c00000) --- --disable-rpath is in use: http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath That is broken in all ways. It is neither the host F-16 system nor the guest F-15 system. It uses scripts built for F-15 Python with F-16 Python. It tries to use debuginfos from F-15 guest with F-16 host. All I asked was to run the "gdb" binary. If I wanted to change the debuginfo path or LD_LIBRARY_PATH etc. I could ask for or even use chroot but I did not. And it does not make sense to discuss what is better or worse, it is only important the standard is to not do directories relocation. There exist enough system features (chroot, LD_LIBRARY_PATH etc.) to do arbitrary directory relocations when one needs to. All the Python, debuginfo etc. paths are already tricky enough which I know from the GDB Fedora packaging issues. According to recent #gdb discussion Debian still does not have working pretty printers after 3 years, the directories difficulties may be one of the reasons. If the tools try to even "randomly" modify the directories on their own each run it is a troubleshooting nightmare. > > GDB is still a bit exotic codebase nowadays, there is a long way to make it > > a normal application with codebase for easy contributions: > >        http://sourceware.org/gdb/wiki/ProjectIdeas > >                Here are some specific internal cleanups that are worth doing: > > I don't understand how this is dispositive to this thread. For example the point I added recently: GDB/binutils no longer support pre-ANSI C compilers. But include/ansidecl.h still contains support for #define PTR char * and other K&R statements. Substitute these obsolete macros everywhere for their ANSI C variant and remove their definition. Check als the GCC source tree using include/ansidecl.h. That xmalloc returns PTR (and not void * like malloc does) and that PTR can be char * in one #ifdef path in include/ansidecl.h and that some GDB code really casts all the xmalloc results together with archer-ratmice-compile-Wc++-compat and switches of GDB to C++ discussions where in C++ one does need to cast void * create a maze of possibilities what is the right way to allocate memory I had difficulties even just allocating a memory in GDB as a newbie. How easier would be if xmalloc just returned void * and the GDB codebase did not case xmalloc results everywhere, like every other package does (using either malloc directly or some NULL-checking equivalent instead). I find casting xmalloc results the same code mystery making contributions difficult like when one sees in code open of a file by filename while the code has its FILE * at hand. Both cases indicate I do not understand the code I am trying contribute to. > > But sure if there is consensus it cannot be fixed in FSF GDB I can move the > > fix to Fedora GDB, there is now already ~50 to-be-merged patches. > > Only 50? It's getting better then. 1/2 :-) It was 55 in 2010, it is only 41 now, it is a real a progress (sure it is thanks to FSF GDB progress by all the contributors making just some of the Fedora patches obsolete, not just by upstreaming them myself). > btw, my main concern is the nature of the test on windows, and hoping > there is a better way to do this. I do not think MS-Windows can be fixed so I find right to have correct code on normal platforms and best-effort on MS-Windows. Sure I am open to better workarounds of MS-Windows but I do not have the platform available + willingness to spend more than required-for-GDB time on that platform myself. > For reference sake, and I don't know if/when we'll switch to 3.x, or > support 2.x and 3.x, but Python 3.x uses fds not FILE*s. > [PyFile_FromFile is gone, and 3.x has PyFile_FromFd] fd vs. FILE * I find a coding detail. I find important the point of never regressing GDB on correctly behaving platform just due to some other broken platform. Thanks, Jan