Re: [PATCH 4/6] DWARF Two Level Line Tables: lnp_state_machine, lnp_reader_state

[Doug Evans <dje at google dot com>]

On Wed, Jun 10, 2015 at 12:44 PM, Simon Marchi
<simon.marchi@ericsson.com> wrote:
> On 15-05-27 06:21 PM, Doug Evans wrote:
>> Doug Evans writes:
>>   > Hi.
>>   >
>>   > This patch puts the line number state machine into a struct
>>   > to make it clear exactly what is part of the state machine
>>   > and what is not. Previously, gdb just had a bunch of local variables.
>>   >
>>   > 2015-03-12  Doug Evans  <dje@google.com>
>>   >
>>   >   * dwarf2read.c (lnp_state_machine): New typedef.
>>   >   (lnp_reader_state): New typedef.
>>   >   (dwarf_record_line_1): Renamed from dwarf_record_line.
>>   >   All callers updated.
>>   >   (dwarf_record_line): New function.
>>   >   (init_lnp_state_machine): New function.
>>   >   (check_line_address): Replace p_record_line parameter with state.
>>   >   All callers updated.
>>   >   (dwarf_decode_lines_1): Call dwarf_record_line, init_lnp_state_machine.
>>   >   Update to record state in lnp_state_machine.
>>
>> Here is what I committed.
>> Just a few comment changes to remove references to two level
>> line tables, which are in a later patch.
>
> Hi Doug,
>
> I have a little question about something this patch. One behaviour changed,
> but I don't know if it was intentional or not. I assume it is not, since the goal
> of this patch was to refactor/cleanup.
>
> When reading full symbols, after an end_sequence, dwarf_finish_line was called
> unconditionally. Now, the call to dwarf_finish_line is guarded by:
>
>     if (state->last_subfile != current_subfile) {
>
> Before this patch, the two other calls to dwarf_finish_line were guarded by this if.
> However, the third one wasn't. Is this change intentional?
>
> I am asking this because that call is apparently important for gdb to properly
> understand DWARF generated by one of our internal compiler. To restore the previous
> behaviour, I did the following. Would it make sense to have the same change in FSF's gdb?
>
> ---8<---
>
> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
> index 1e290c3..d79b2e3 100644
> --- a/gdb/dwarf2read.c
> +++ b/gdb/dwarf2read.c
> @@ -17658,7 +17658,7 @@ dwarf_record_line (lnp_reader_state *reader, lnp_state_machine *state,
>        lh->file_names[file - 1].included_p = 1;
>        if (reader->record_lines_p && is_stmt)
>         {
> -         if (state->last_subfile != current_subfile)
> +         if (state->last_subfile != current_subfile || end_sequence)
>             {
>               dwarf_finish_line (reader->gdbarch, state->last_subfile,
>                                  state->address, state->record_line);
>
> --->8---

Yikes.
My bad, thanks for catching this.

LGTM