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
next prev 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).