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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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

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