From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15223 invoked by alias); 24 Jan 2012 18:32:35 -0000 Received: (qmail 15164 invoked by uid 22791); 24 Jan 2012 18:32:33 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,TW_FD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 18:32:19 +0000 Received: by vbbfd1 with SMTP id fd1so1994284vbb.0 for ; Tue, 24 Jan 2012 10:32:18 -0800 (PST) Received: by 10.52.90.71 with SMTP id bu7mr6844245vdb.63.1327429938721; Tue, 24 Jan 2012 10:32:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.90.71 with SMTP id bu7mr6844235vdb.63.1327429938627; Tue, 24 Jan 2012 10:32:18 -0800 (PST) Received: by 10.220.229.1 with HTTP; Tue, 24 Jan 2012 10:32:18 -0800 (PST) In-Reply-To: <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> <20120124143609.GA20367@host2.jankratochvil.net> Date: Tue, 24 Jan 2012 18:56:00 -0000 Message-ID: Subject: Re: [patch] Do not open Python scripts twice #2 [Re: [RFC] Crash sourcing Python script on Windows] From: Doug Evans To: Jan Kratochvil Cc: Pedro Alves , Joel Brobecker , gdb-patches@sourceware.org X-System-Of-Record: true X-Gm-Message-State: ALoCoQmmnyT/d+FMu1LDj7Hff5ilKYXNqlz2DUuQ3NJEfPkXAY+tWf1z4x+C1ByumK37gwhdGxSLgznJolJ6ZE1TVQwW3upDb8jFZ5Ar6nOaGDlj7uVJrArwueSMpHoA9XP2dyQxMgY2x4L1bbhVegkoc73cGA/Zvw== Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00836.txt.bz2 On Tue, Jan 24, 2012 at 6:36 AM, Jan Kratochvil wrote: > 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 Fedor= a - as >> > it is not a normal native application behavior - and in some corner ca= ses it >> > even breaks execution. >> >> Huh. =A0Can 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 =A0 0 Jan 24 15:06 /var/lib/mock/fedora-15-x86_64/= root/var/mail/root > # mutt > =A0--- The mail (785 bytes) is displayed correctly. > # /var/lib/mock/fedora-15-x86_64/root/usr/bin/mutt > =A0--- 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. > =A0--- 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/mkd= ir > Try: yum --disablerepo=3D'*' --enablerepo=3D'*-debuginfo' install /var/li= b/mock/fedora-15-x86_64/root/usr/lib/debug/.build-id/93/d9b3a3ab008848c7cb7= 3979e6d7a6bb1256e28.debug > (no debugging symbols found)...done. > =A0--- GDB is broken! =A0Why it reads some weird paths? =A0I just ran the= gdb binary. > =A0--- These GDB variants here still contain the FSF GDB directory reloca= tions. > =A0vvv > (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 > =A0 =A0 =A0 =A0libpython2.7.so.1.0 =3D> /usr/lib64/libpython2.7.so.1.0 (0= x0000003690c00000) > =A0--- --disable-rpath is in use: http://fedoraproject.org/wiki/Packaging= :Guidelines#Beware_of_Rpath I can understand not wanting debug-file-directory to "move" in this particular case, but I wouldn't necessarily want to remove the relocatability. [IOW, remembering that debug-file-directory is misnamed, sigh, it can have multiple directories. Fedora could have a system-wide debug file directory that didn't move and one tied to gdb's installation directory that did move (and, obviously, remove dups).] OTOH, what's in this directory is less specific to the gdb being run, it makes less sense for this directory to be relocatable. OTOOH, changing things may break something, so if you wanted to add --with-system-separate-debug-dir or a way to specify --with-separate-debug-dir that wasn't relocatable (even though it otherwise would be), or some such, I think that'd be ok. As for PYTHONDIR, what's in this directory is (supposed to be) particular to that gdb. I've been thinking IWBN to have another directory for things not specific to a particular gdb, but python already has a "site" directory for such things ("site-packages" or some such) so I haven't pursued it. > [...]=A0It uses scripts built for F-15 Python with F-16 Python. Rather, it's using scripts for F-15 GDB with F-16 Python, because that's what you asked for. If you want to run F-15 GDB with F-15 python, then do that ... [and if there are problems there, fix 'em; but they're not because F-15 gdb is using its own scripts] > It tries to use debuginfos from F-15 guest with F-16 host. > > All I asked was to run the "gdb" binary. =A0If I wanted to change the deb= uginfo > 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. Well, the important thing is to pick what works for the right reasons, not introduce unwarranted incompatibilities, etc. > There exist > enough system features (chroot, LD_LIBRARY_PATH etc.) to do arbitrary > directory relocations when one needs to. [AIUC] I'd instead impose requiring chroot on Fedora package testers than regular users. > All the Python, debuginfo etc. paths > are already tricky enough which I know from the GDB Fedora packaging issu= es. > According to recent #gdb discussion Debian still does not have working pr= etty > printers after 3 years, the directories difficulties may be one of the > reasons. =A0If the tools try to even "randomly" modify the directories on= their > own each run it is a troubleshooting nightmare. These are qualitative assessments that I can't really address ... I could label almost anything in computerdom as "tricky". If Debian still doesn't have working pretty-printers, well they're smart people, I'd like to hear more details ... I wouldn't want to base decisions on "[...] *may* be one of the reasons." [emphasis added] > >> > GDB is still a bit exotic codebase nowadays, there is a long way to ma= ke it >> > a normal application with codebase for easy contributions: >> > =A0 =A0 =A0 =A0http://sourceware.org/gdb/wiki/ProjectIdeas >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Here are some specific internal cleanup= s that are worth doing: >> >> I don't understand how this is dispositive to this thread. > > For example the point I added recently: > =A0 =A0 =A0 =A0GDB/binutils no longer support pre-ANSI C compilers. But > =A0 =A0 =A0 =A0include/ansidecl.h still contains support for #define PTR = char * and > =A0 =A0 =A0 =A0other K&R statements. Substitute these obsolete macros eve= rywhere for > =A0 =A0 =A0 =A0their ANSI C variant and remove their definition. Check al= s the GCC > =A0 =A0 =A0 =A0source tree using include/ansidecl.h. > > That xmalloc returns PTR (and not void * like malloc does) and that PTR c= an be > char * in one #ifdef path in include/ansidecl.h and that some GDB code re= ally > casts all the xmalloc results together with archer-ratmice-compile-Wc++-c= ompat > 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. =A0Both cases indicate I do not understand the co= de I am > trying contribute to. That still doesn't help me decide whether this patch should go in (as is). If you wanted to punt on windows and just always impose a double open(), I'd be ok with that, for example. > >> > But sure if there is consensus it cannot be fixed in FSF GDB I can mov= e the >> > fix to Fedora GDB, there is now already ~50 to-be-merged patches. >> >> Only 50? =A0It's getting better then. =A01/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 co= de on > normal platforms and best-effort on MS-Windows. =A0Sure I am open to bett= er > 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. =A0I find important the point of ne= ver > regressing GDB on correctly behaving platform just due to some other brok= en > platform. That was just a "for reference sake" remember ...