This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling

On Tue, Jul 3, 2012 at 5:54 AM, Jan Kratochvil
<> wrote:
>> - If it does actually fix the bug in question it seems more accidental
>> than on purpose.
> I do not see why you think so.

I think I was confused about something.

>> - If we really want to take this step then start,end on global,static
>> blocks needs to go.
> <abstract chat>
> GDB needs some BLOCK_START / BLOCK_END abstraction for things like sorting
> blocks and finding the most narrow block etc.
> GDB needs some abstraction of the code.  For -O2 -g code in fact there are no
> longer any source statements boundaries, there is no execution order etc.  The
> abstraction of inferior for the purposes of GDB user interface will be
> probably always broken in some way for -O2 -g code as for real -O2 -g code one
> cannot simplify it more than what 'disas' shows.
> This patch tries to exactly match process_psymtab_comp_unit_reader and
> dw2_do_instantiate_symtab.  I call it a bugfix.  I do not try to redesign GDB
> in this patch.
> Whether BLOCK_END or BLOCK_START could be removed is more a GDB design change.
> Currently it is a fallback for GDB code not yet prepared to use
> BLOCKVECTOR_MAP.  As usual in GDB there are kept both the older and modern
> ways how to do things as nobody wants to update all the code in GDB at once so
> we could drop the old code.
> </abstract chat>

Note that I was specifically referring to GLOBAL and STATIC blocks.
There the concept of having a start and end has lost its meaning.
They have a lower bound and an upper bound which may be useful in
sorting, but using their start/end values as start/end values is

>>   Until then we're just satisfying a desire to apply dwarf correctly
>> without really accomplishing anything.
> I tried to exploit some case where the patch of mine behaves more correctly
> than the patch of yours but I cannot.  Any code which accesses STATIC_BLOCK's
> assigned ranges already checks first objfile->psymtabs_addrmap which already
> has exactly correct CU's DW_AT_ranges map.

I was playing with a case of "pc 0x42 in read in psymtab, but not in
symtab" case today.
gdb has other problems that get in the way, but having more
consistency between partial and full syms has to be a good thing.
[btw, seems kinda odd to have two addrmaps: one for psymtabs/index and
one for fullsyms.  I wonder if there's an opportunity here.]

Here's an updated version of your patch to match the current tree.

2012-07-11  Jan Kratochvil  <>
            Doug Evans  <>

        * buildsym.c (end_symtab_1): Split it to ...
        (end_symtab_get_static_block): ... this ...
        (end_symtab_from_static_block): ... and this function.
        (end_symtab, end_expandable_symtab): Call them.
        * buildsym.h (end_symtab_get_static_block)
        (end_symtab_from_static_block): New declarations.
        * dwarf2read.c (process_full_comp_unit): New variable static_block.
        Set its valid CU ranges.

Attachment: gdb-120711-static-block-ranges-1.patch.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]