Re: [PATCH 3/4] aix: add support for dwarf2.

[Tristan Gingold <gingold@adacore.com>]

On May 24, 2011, at 3:36 PM, Tom Tromey wrote:

>>>>>> "Tristan" == Tristan Gingold <gingold@adacore.com> writes:
> 
> Tristan> +  if (this_symtab_psymtab == NULL)
> Tristan> +    return;
> 
> Tom> I don't understand this change.
> 
> Tristan> This is just a guard.  process_linenos (called by
> Tristan> aix_process_linenos) will dereference this_symtab_psymtab,
> Tristan> which is set by read_xcoff_symtab.  However, if the psymtab is
> Tristan> built by dwarf2, the variable will never be initialized.
> 
> Tristan> Do you think the issue is somewhere else ?
> 
> It is very unclear to me whether this can be non-NULL even with DWARF.
> In the DWARF case wouldn't the line information come from the DWARF line
> table?  In which case it seems like xcoffread.c should have a second
> struct sym_fns, with a NULL entry for this method.

Tom,

here is my understanding of the issue.

aix_process_linenos is called by end_symtab.
In the case of a standard xcoff binary, a symtab is created only if debugging symbols are present and everything is consistent.
In the case of an xcoff binary compiled without debug info, no symtab is created.

In the case of a dwarf xcoff binary, a symtab is created (by dwarf2read), and the call to aix_process_linenos crashes because of
a non-consistent state within xcoffread.  I am not sure that we could have a second sym_fns, as an objfile can have both dwarf2 and
stabs debug info.

In fact this_symtab_psymtab is NULL with dwarf, as it is set only by read_xcoff_symtab, which is called only numsyms != 0.  This happens only when linenos are present.

I fear that adding a second sym_fns will be harder to manage than the proposed guard.

What do you think ?

Tristan.