public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, macro@mips.com
Subject: Re: [RFA 1/2] Make line tables independent of progspace
Date: Wed, 28 Mar 2018 03:34:00 -0000	[thread overview]
Message-ID: <bd32c496-efff-db2c-1c0b-d1de276d356c@simark.ca> (raw)
In-Reply-To: <87vadiw24a.fsf@tromey.com>

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

  parent reply	other threads:[~2018-03-28  3:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 17:18 [RFA 0/2] " Tom Tromey
2018-03-21 17:18 ` [RFA 2/2] Constify the line table Tom Tromey
2018-03-21 17:18 ` [RFA 1/2] Make line tables independent of progspace Tom Tromey
2018-03-24  3:40   ` Simon Marchi
2018-03-27  4:16     ` Tom Tromey
2018-03-27  4:53       ` Tom Tromey
2018-03-27 20:22         ` Simon Marchi
2018-03-28  4:53           ` Tom Tromey
2018-03-28 12:30             ` Simon Marchi
2018-03-28  3:34         ` Simon Marchi [this message]
2018-03-28  5:02           ` Tom Tromey
2018-03-28 12:32             ` Simon Marchi
2018-03-28 19:33           ` Maciej W. Rozycki
2018-03-29 15:04             ` Simon Marchi
2018-03-29 21:07               ` Maciej W. Rozycki
2018-04-26 21:30                 ` Tom Tromey
2018-05-03 23:17                   ` Maciej W. Rozycki
2018-05-14 23:54                     ` Maciej W. Rozycki

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=bd32c496-efff-db2c-1c0b-d1de276d356c@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@mips.com \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).