public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@ericsson.com>,
	Simon Marchi <simon.marchi@polymtl.ca>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] dwarf: Make sect_offset 64-bits
Date: Tue, 20 Feb 2018 16:49:00 -0000	[thread overview]
Message-ID: <b9b9ca12-3a19-1356-b317-51356e4aafb2@redhat.com> (raw)
In-Reply-To: <09806ce5-3e85-dacc-cf3e-22660fab90b8@ericsson.com>

On 02/20/2018 04:38 PM, Simon Marchi wrote:
> On 2018-01-28 12:26 PM, Simon Marchi wrote:
>> Does anybody have an opinion about this?  It would be nice to unbreak
>> the "default" build with clang (i.e. without passing special -Wno-error=
>> flags).
>>
>> Here's a version rebased on today's master.
> 
> Ping.
> 

Does this change the type of any field of the structures that form the
indexes?  I.e., does it affect binary compatibility there?  I.e.,
can you save a gdb index with pre-patch gdb, and load it back in
post-patch gdb.  Likewise viceversa.  Also DWARF5 indexes.

Also, just for the record, can we assume that this doesn't increase
memory usage considerably when debugging bigger programs?  I assume that
this will create some padding holes in some structures and that we can
probably win back the memory by just changing order of some fields
for better packing.

Offhand, I know about code in dwarf2read.c that assumes that offset_type
is 32-bit for both of the reasons above -- memory usage (e.g.,
struct name_component), and also as type used in indexes.
I'm not seeing anything for sect_offset, but can you double check?

Thanks,
Pedro Alves

  reply	other threads:[~2018-02-20 16:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-31  3:48 Simon Marchi
2018-01-28 17:26 ` Simon Marchi
2018-02-20 16:38   ` Simon Marchi
2018-02-20 16:49     ` Pedro Alves [this message]
2018-02-22 21:42       ` Simon Marchi
2018-02-23 16:56         ` Pedro Alves
2018-02-23 18:04           ` Simon Marchi

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=b9b9ca12-3a19-1356-b317-51356e4aafb2@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.com \
    --cc=simon.marchi@polymtl.ca \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).