Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Craig Silverstein <csilvers@google.com>
Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org
Subject: Re: Patch to handle compressed sections
Date: Thu, 17 Apr 2008 16:24:00 -0000	[thread overview]
Message-ID: <20080417161526.GF17488@caradoc.them.org> (raw)
In-Reply-To: <20080414234559.A3AA03F23CF@localhost>

Just a general comment - I've been seeing a lot of gold patches
lately where gold doesn't have a certain piece of data available at a
certain point... that seems like a really underwhelming reason to
use a big endian size in an otherwise little endian file.  But
as I said earlier, the choice of header format is pretty arbitrary,
and anyone prepared to read DWARF ought to be able to cope with a
simple big endian integer!  So that's fine.

On Mon, Apr 14, 2008 at 04:45:59PM -0700, Craig Silverstein wrote:
> +/* When loading sections, we can either look for ".<name>", or for
> + * ".z<name>", which indicates a compressed section.  */
> +
> +static int
> +section_is_p(asection *sectp, const char *name)

Space before parenthesis.

> +  /* Read the zlib header.  In this case, it should be "ZLIB" followed
> +     by the uncompressed section size, 8 bytes in big-endian order.  */
> +  if (compressed_size < header_size
> +      || strncmp (compressed_buffer, "ZLIB", 4) != 0)
> +    error (_("Dwarf Error: Corrupt DWARF ZLIB header from '%s'"),
> +           bfd_get_filename (abfd));
> +  uncompressed_size = compressed_buffer[4]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[5]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[6]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[7]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[8]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[9]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[10]; uncompressed_size <<= 8;
> +  uncompressed_size += compressed_buffer[11];

You can use bfd_getb64.

>    buf = obstack_alloc (&objfile->objfile_obstack, size);
> +  /* When debugging .o files, we may need to apply relocations; see
> +     http://www.cygwin.com/ml/gdb-patches/2002-04/msg00136.html .
> +     We never compress sections in .o files, so we only need to
> +     try this when the section is not compressed.  */

Use the sourceware.org URL instead, please.  Actually, it'd make me
happy if you couldn't get at these archives via cygwin.com.  It
confuses search results...

Aside from that, this is fine to commit.  Do you have write access?
If not, request it using the sourceware form - if you have write
access to binutils then you already do.  Then add yourself to write
after approval in MAINTAINERS and check in the final patch.

The other things needed for this feature are, IMO:

  - A NEWS entry.
  - An entry in the manual.  I'm not sure where, but the format
    of the sections should probably be described in the GDB manual
    somewhere.
  - An addition to the "Requirements" section of the GDB manual,
    explaining why you should have zlib.

Could you follow up with those, please?  The other thing I very
much want is an objcopy option to compress DWARF sections, but
that's clearly beyond the call of duty.  That will let GNU ld
users take advantage of this and is probably easier than teaching GNU
ld to compress .debug_info (though that would be nice, too).

Other tools that would benefit from reading such sections include
readelf and addr2line (bfd/dwarf2.c).

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2008-04-17 16:15 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
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 [this message]
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=20080417161526.GF17488@caradoc.them.org \
    --to=drow@false.org \
    --cc=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