Re: abrt wishlist
> "Jan" == Jan Kratochvil writes: Jan> GDB on client side would need something like readonly NFS-like Jan> service to load the .debug files byte-wise. And this NFS-like Jan> service network protocol must be signed by Fedora project like the Jan> current rpms are. Jan> Then the fast operation of GDB on the client depends on these known Jan> issues: Jan> * http://fedoraproject.org/wiki/Features/GdbIndex which is now Jan> present in F14 updated packages (but it still was not present in Jan> F14 GA packages). Jan>* Recheck THe .debug files reading via .gdb_index is really Jan>optimal for the network protocol. I assume it isn't. The core of the index is a memory-mapped hash table. GDB will access it in essentially random order. Jan> * Fixing GDB to not ever touch .debug files for libraries not going to be Jan>used in the specific backtrace at all. This seems like a good idea. Maybe GDB could detect that the debug info is remote and defer the reading only in this case. Even if we don't read the debug info, we probably still want to read any python code associated with the library. Another idea we could implement is do index queries over the net, say using a remote SQL server. This means more round trips, but less data to download. Maybe this isn't really the right tradeoff -- but the point is that we have a lot of leeway to change GDB, we don't have to try to work around it. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gdb index feature
We're going to be pushing in a new gdb feature that creates indices for the debuginfo. These indices are created by gdb, then merged into the executable or shared library using objcopy. This will be done as part of the find-debuginfo.sh script, run by RPM. The point of this change is that it greatly speeds up gdb startup. It also greatly reduces gdb memory use. I am not completely sure when all the work will appear in rawhide, but I wanted to send a short warning in case something is broken. If this process causes some problem, please report it against "gdb" in bugzilla, and somebody will look at it ASAP. thanks, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sharutils license correction
Paul> "convert all info pages to proper man pages and obsolete: the info Paul> package." Man pages aren't really a replacement for info. Replacing info with HTML would be more reasonable, but would be a significant step backward in usability for Emacs users and perhaps others. This is solvable, but I think better solved upstream. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abrt (was Re: Most buggy packages)
> "David" == David Malcolm writes: David> In particular, for scripting languages, David> it's most useful to be able to extract the script-level backtrace from David> the C-level stack (i.e. "what was the Python code doing?") FWIW we're adding direct support for this to gdb. You'll be able to supply backtrace filters with your project just as you currently can provide value and type pretty-printers. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abrt (was Re: Most buggy packages)
David> In particular, for scripting languages, David> it's most useful to be able to extract the script-level backtrace from David> the C-level stack (i.e. "what was the Python code doing?") Tom> FWIW we're adding direct support for this to gdb. Tom> You'll be able to supply backtrace filters with your project just as you Tom> currently can provide value and type pretty-printers. Jiri> Does it mean just dropping a python script to some directory and GDB Jiri> will call this script when processing a specific coredump? Or does the Jiri> caller (abrt or user) have to manually instruct gdb to use it? It will work just like pretty printers -- so, automatic if that is what the package maintainers want to do. At least, that is the situation for CLI users. MI clients will have to request the new behavior, because it changes MI output. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel