Hi,
# https://fedorahosted.org/abrt/wiki/RFE # RETRACE SERVER # * recreating the bt means: # o downloading the required debuginfo (if it's not cached) # o replacing the ???? with proper function names # o add a line numbers pointing to source file
Backtracing without debuginfo cannot provide the complete information now (it misses inlined frames) and more features in development + planned also could not be supported in the future. Preview of the latter is shown at: Re: [PATCH] Debug info extensions to support optimized out parameters http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00385.html
Since Fedora 14 GDB supports .gdb_index (by Tom Tromey) and therefore now debuginfofs has started to make sense. It made no sense before as GDB read the whole .debug file first just to index it; this is no longer true and only the small .gdb_index section is being read in. http://fedoraproject.org/wiki/Features/DebuginfoFS
debuginfofs can provide the same debug info features as an upload of the whole core file; the core upload is not feasible for security reasons.
Still it means retrace server cannot do the backtracing task, this has to be done at the client side - for security reasons.
Which network protocol, its signing and what servers to use for DebuginfoFS remains a question. Also .gdb_index has been developed with the goal of improved on-disk performance; a network filesystem performance may need more tuning. GDB could also use some file access library (neon as an example) for the .debug files access avoiding the need of mounting any network filesystem.
Regards, Jan
On 09/15/2010 10:53 AM, Jan Kratochvil wrote:
Since Fedora 14 GDB supports .gdb_index (by Tom Tromey) and therefore now debuginfofs has started to make sense. It made no sense before as GDB read the whole .debug file first just to index it; this is no longer true and only the small .gdb_index section is being read in. http://fedoraproject.org/wiki/Features/DebuginfoFS
Nice. We should probably set up a test server somewhere to see how it works.
debuginfofs can provide the same debug info features as an upload of the whole core file; the core upload is not feasible for security reasons. Still it means retrace server cannot do the backtracing task, this has to be done at the client side - for security reasons.
Can you elaborate on the security reasons, please?
You can trust the retrace server provider like you trust a provider of cloud computing system, a virtual server, or a web application, can't you?
Which network protocol, its signing and what servers to use for DebuginfoFS remains a question. Also .gdb_index has been developed with the goal of improved on-disk performance; a network filesystem performance may need more tuning. GDB could also use some file access library (neon as an example) for the .debug files access avoiding the need of mounting any network filesystem.
Thanks for the info.
Karel
On Wed, 15 Sep 2010 16:32:57 +0200, Karel Klic wrote:
On 09/15/2010 10:53 AM, Jan Kratochvil wrote:
Since Fedora 14 GDB supports .gdb_index (by Tom Tromey) and therefore now debuginfofs has started to make sense. It made no sense before as GDB read the whole .debug file first just to index it; this is no longer true and only the small .gdb_index section is being read in. http://fedoraproject.org/wiki/Features/DebuginfoFS
Nice. We should probably set up a test server somewhere to see how it works.
This implementation is for example using FUSE, which I personally do not find as needlessly complicated and I would prefer. I thought about this project more as a design principle.
debuginfofs can provide the same debug info features as an upload of the whole core file; the core upload is not feasible for security reasons. Still it means retrace server cannot do the backtracing task, this has to be done at the client side - for security reasons.
Can you elaborate on the security reasons, please?
You can trust the retrace server provider like you trust a provider of cloud computing system, a virtual server, or a web application, can't you?
That is the retrace server must be provided on hosts trusted by fedoraproject and the communication must be signed by fedoraproject keys, I agree. (One could think also about a model where the retrace server is not trusted, from a cloud provided by the Fedora community.)
While it is technically safe I do not feel right to for example send a cleartext password inisde a core file to a fedoraproject server, do you? Maybe it is OK, not sure.
Still you need some form of debuginfofs; without the .debug files you cannot retrieve enough information from the core file for the later retrace by the retrace server (for example the local variables).
I would probably rather leave the security investigation of the design on the TH security staff.
Thanks, Jan
"Jan" == Jan Kratochvil jan.kratochvil@redhat.com writes:
Jan> Since Fedora 14 GDB supports .gdb_index (by Tom Tromey) and Jan> therefore now debuginfofs has started to make sense. It made no Jan> sense before as GDB read the whole .debug file first just to index Jan> it; this is no longer true and only the small .gdb_index section is Jan> being read in.
Recently I have been thinking that maybe we could improve the quick-lookup API inside gdb, and then we could have some kind of index server.
That is: right now if we tried to do debuginfofs, we'd have to download all the .gdb_index sections. Then, we'd need the full debuginfo for any section read by gdb.
It seems like we could do better if we changed gdb.
First, we could have all the quick functions do RPCs to the debuginfo server. On the server we could pre-scan all the DWARF and put the results into a database for easy lookup.
Then, perhaps we could modify the DWARF reader to need only data for particular CUs. Or, perhaps we could deliver the data in some new, simpler format.
This is a fair amount of work, both inside gdb and on the server.
Tom
crash-catcher@lists.fedorahosted.org
-
Jan Kratochvil -
Karel Klic -
Tom Tromey