Re: [patch] Do not open Python scripts twice #2 [Re: [RFC] Crash sourcing Python script on Windows]

[Doug Evans <dje at google dot com>]

On Tue, Jan 24, 2012 at 6:36 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 23 Jan 2012 23:47:12 +0100, Doug Evans wrote:
>> On Mon, Jan 23, 2012 at 2:17 PM, Jan Kratochvil <jan.kratochvil@redhat.com> 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

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.

> [...]?It 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. ?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.

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

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

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

That was just a "for reference sake" remember ...