This is the mail archive of the gdb-patches@sourceware.org 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 1/2] Make line tables independent of progspace


On 2018-03-27 12:53 AM, Tom Tromey wrote:
> Tom> I've run the new patch through the buildbot.  I'll resubmit it soon, I
> Tom> just have to update the ChangeLog and rewrite the commit message.
> 
> Here it is.  Let me reiterate that this probably requires careful review
> as the buildbot may not test some of these paths.

Hi again,

I took another look.  For the old debug info formats, it's really hard to tell if
the code is right, since we don't have automated tests or even a manual way to test,
for most of them.  But I don't think that should hinder improvements to the formats
that are actually used today.  I think the changes you did are a good "best effort".

If we judge that the old formats are not useful anymore and have most likely
bit-rotten with time, we should think about removing them eventually.

Anyway, I just have some small comments here, otherwise the patch LGTM.  Maybe
it would be a good idea to get the opinion of Maciej (in CC) for the
addr_bits_remove part?

> @@ -3209,13 +3219,17 @@ find_pc_sect_line (CORE_ADDR pc, struct obj_section *section, int notcurrent)
>  
>        /* Is this file's first line closer than the first lines of other files?
>           If so, record this file, and its first line, as best alternate.  */
> -      if (item->pc > pc && (!alt || item->pc < alt->pc))
> -	alt = item;
> +      if (item->address (iter_s) > pc
> +	  && (!alt || (item->address (iter_s) < alt->address (alt_symtab))))
> +	{
> +	  alt = item;
> +	  alt_symtab = iter_s;
> +	}
>  
> -      auto pc_compare = [](const CORE_ADDR & pc,
> -			   const struct linetable_entry & lhs)->bool
> +      auto pc_compare = [=](const CORE_ADDR & pc,
> +			    const struct linetable_entry & lhs)->bool
>        {
> -	return pc < lhs.pc;
> +	return pc < lhs.address (iter_s);
>        };

Since we know this will be called many times and address() is substantially
more costly than just reading a CORE_ADDR field, maybe it would be good to
save it to a variable before and use that in the lambda.  I was also thinking
the same thing for the various other calls to address() in this function, since
sometimes the same value is recomputed multiple times.  For example,
"item->address (iter_s)" in

      if (best && item < last
	  && (item->address (iter_s) > best->address (best_symtab))
          && (best_end == 0 || best_end > item->address (iter_s)))
	best_end = item->address (iter_s);

> @@ -1227,8 +1228,45 @@ struct rust_vtable_symbol : public symbol
>  
>  struct linetable_entry
>  {
> -  int line;
> -  CORE_ADDR pc;
> +  /* Set the members of this object.  */
> +  void set (int line_, CORE_ADDR pc)
> +  {
> +    m_line = line_;
> +    m_pc = pc;
> +  }
> +
> +  /* Set the members of this object from another linetable_entry.  */
> +  void set (const linetable_entry &other)
> +  {
> +    m_line = other.m_line;
> +    m_pc = other.m_pc;
> +  }

This really looks like an assignment operator (the default one would be
enough).  Is there a reason to have this set overload?  Either way works,
I'm just curious.

> @@ -499,19 +505,20 @@ arrange_linetable (struct linetable *oldLineTb)
>      {
>        /* If the function was compiled with XLC, we may have to add an
>           extra line to cover the function prologue.  */
> -      jj = fentry[ii].line;
> +      jj = fentry[ii].line ();
>        if (jj + 1 < oldLineTb->nitems
> -	  && oldLineTb->item[jj].pc != oldLineTb->item[jj + 1].pc)
> +	  && (oldLineTb->item[jj].raw_address ()
> +	      != oldLineTb->item[jj + 1].raw_address ()))
>  	{
> -	  newLineTb->item[newline] = oldLineTb->item[jj];
> -	  newLineTb->item[newline].line = oldLineTb->item[jj + 1].line;
> +	  newLineTb->item[newline].set (oldLineTb->item[jj].raw_address (),
> +					oldLineTb->item[jj + 1].line ());

The address and the line are inverted here.

Thanks,

Simon


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