From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, tromey@redhat.com, palves@redhat.com
Subject: Re: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling
Date: Fri, 22 Jun 2012 20:51:00 -0000 [thread overview]
Message-ID: <CADPb22QB0czUev9oKXv9LHHK6H1T=8JhFa0whErojZC+cdrdBw@mail.gmail.com> (raw)
In-Reply-To: <20120622193539.GA7344@host2.jankratochvil.net>
On Fri, Jun 22, 2012 at 12:35 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 05 Jun 2012 03:14:46 +0200, Doug Evans wrote:
>> --- buildsym.c 29 May 2012 20:23:17 -0000 1.97
>> +++ buildsym.c 5 Jun 2012 00:26:01 -0000
>> @@ -1024,8 +1027,15 @@ end_symtab (CORE_ADDR end_addr, struct o
>> {
>> /* Define the STATIC_BLOCK & GLOBAL_BLOCK, and build the
>> blockvector. */
>> - finish_block (0, &file_symbols, 0, last_source_start_addr,
>> - end_addr, objfile);
>> + struct block *static_block;
>> +
>> + static_block = finish_block (0, &file_symbols, 0,
>> + last_source_start_addr, end_addr,
>> + objfile);
>> + /* Mark the range of the static block so that if we end up using
>> + blockvector.map then find_block_in_blockvector behaves identically
>> + regardless of whether the addrmap is present. */
>> + record_block_range (static_block, last_source_start_addr, end_addr - 1);
>
> On IRC Doug made a note:
> Arguably the second is the better fix but it's still a hack as
> addrmaps are intended to handle discontiguous symtabs and this defeats
> that.
>
> Where "the first fix" was:
> [RFA] Fix gdb segv in dw2_find_pc_sect_symtab
> http://sourceware.org/ml/gdb-patches/2012-05/msg00958.html
>
> I think the right way is to call dwarf2_record_block_ranges for
> DW_AT_compilation_unit but I haven't tried to write such patch yet, is there
> a problem?
>
>
>> finish_block_internal (0, &global_symbols, 0, last_source_start_addr,
>> end_addr, objfile, 1);
>> blockvector = make_blockvector (objfile);
With some work that could be made to work.
But remember that the static block (or global block) doesn't exist
until the call to end_symtab, and, barring even more work, you need to
get the range into pending_addrmap before the call to make_blockvector
where pending_addrmap is turned into a fixed addrmap.
next prev parent reply other threads:[~2012-06-22 20:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 1:15 Doug Evans
2012-06-05 15:06 ` Pedro Alves
2012-06-06 15:54 ` Jan Kratochvil
2012-06-22 18:24 ` ping: " Jan Kratochvil
2012-06-22 19:36 ` Jan Kratochvil
2012-06-22 20:51 ` Doug Evans [this message]
2012-06-24 18:34 ` Jan Kratochvil
2012-06-25 11:39 ` Doug Evans
2012-07-03 12:54 ` Jan Kratochvil
2012-07-12 5:19 ` Doug Evans
2012-07-12 20:30 ` Jan Kratochvil
2012-07-13 20:28 ` [commit] " Jan Kratochvil
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='CADPb22QB0czUev9oKXv9LHHK6H1T=8JhFa0whErojZC+cdrdBw@mail.gmail.com' \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/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