Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@br.ibm.com>
To: Craig Silverstein <csilvers@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Patch to handle compressed sections
Date: Wed, 26 Mar 2008 16:10:00 -0000	[thread overview]
Message-ID: <1206547779.29533.43.camel@localhost.localdomain> (raw)
In-Reply-To: <20080325230440.BF0623F25D6@localhost>

On Tue, 2008-03-25 at 16:04 -0700, Craig Silverstein wrote:
> This patch adds support for reading compressed debug sections, as are
> produced by the new gold linker when it's run with
> --compress-debug-sections=zlib.

Neat. Out of curiosity, does this approach work well in practice? If you
need to compress debug info, it means you are dealing with a very large
amount of it. Isn't it cumbersome for GDB to deal with it later? I
imagine it must be slow to wait for GDB to uncompress and interpret it
all, and it must use a very big amount of memory.

It's a trade-off where you ease the burden on the computer where the
program runs, and permits you to have debuginfo around where you
probably couldn't before, but on the other hand you need a lot of
resources to actually be able to work with that debuginfo in a debug
environment, right?

> +/* Note that if the debugging section has been compressed, it might
> +   have a name like .debug_info.zlib.nnnn (where nnn is the
> +   uncompressed size).  */

I am not as fluent in ELF and DWARF representation as I would like, so
take this for what it's worth:

Encoding this information in the section name looks strange to me. Isn't
it possible to define a new flag in the section's sh_flags to signal
that the section is compressed and then use the first few bytes of the
section contents for the information above?

Or alternatively, create a note section for that? This route might be
easier in that it doesn't raise compatibility concerns, and there's no
immediate need to actually extend the ELF standard.

> +  /* Handle the case of a section compressed using zlib.  */
> +  if (strncmp (compression_type, ".zlib.", sizeof(".zlib.")-1) == 0)
> +    {
> +#ifndef HAVE_ZLIB_H
> +      error (_("Dwarf Error: Can't uncompress zlib-compressed DWARF data "
> +               "in '%s'"),
> +               bfd_get_filename (abfd));
> +#else

I think it's better for this error message to say something along the
lines of "Support for compressed DWARF data is disabled in this copy of
GDB".
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center


  reply	other threads:[~2008-03-26 16:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-25 23:05 Craig Silverstein
2008-03-26 16:10 ` Thiago Jung Bauermann [this message]
2008-03-26 17:40   ` Craig Silverstein
2008-03-26 18:01     ` Daniel Jacobowitz
2008-03-26 18:36       ` Craig Silverstein
2008-04-01 14:28         ` Daniel Jacobowitz
2008-04-02  0:38           ` Craig Silverstein
2008-04-02 12:27             ` Daniel Jacobowitz
2008-04-02 12:51               ` Craig Silverstein
2008-04-02 14:13               ` Andreas Schwab
2008-04-03  7:38               ` Craig Silverstein
2008-04-03  8:45                 ` Craig Silverstein
2008-04-03 11:01                   ` Pedro Alves
2008-04-03 11:10                     ` Pedro Alves
2008-04-03 21:43                     ` Craig Silverstein
2008-04-04  1:28                     ` Craig Silverstein
2008-04-15  6:16                   ` Craig Silverstein
2008-04-17 16:24                     ` Daniel Jacobowitz
2008-04-17 20:57                       ` Craig Silverstein
2008-04-17 21:09                         ` Daniel Jacobowitz
2008-04-19  0:32                           ` Craig Silverstein
2008-04-19  0:13                             ` Daniel Jacobowitz
2008-04-19  0:32                               ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206547779.29533.43.camel@localhost.localdomain \
    --to=bauerman@br.ibm.com \
    --cc=csilvers@google.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox