From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Make a function for block->objfile lookups
Date: Wed, 22 Apr 2009 19:17:00 -0000 [thread overview]
Message-ID: <m31vrkwlaf.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20090422183915.GA20196@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Wed\, 22 Apr 2009 20\:39\:15 +0200")
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> 2009-04-22 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * block.c (block_objfile): New function.
Jan> * block.h (block_objfile): New prototype.
Jan> * objfiles.c (matching_objfiles): New function.
Jan> * objfiles.h (matching_objfiles): New prototype.
Jan> * printcmd.c: Remove include solib.h.
Jan> (display_uses_solib_p): Rename to ...
Jan> (display_uses_objfile): ... a new function name. Change the SOLIB
Jan> parameter to OBJFILE parameter. Use now a matching_objfiles call.
Jan> (clear_dangling_display_expressions): Update the caller.
Jan> +struct objfile *block_objfile (const struct block *block)
Newline after the "*".
Jan> + struct symbol *func;
Jan> +
Jan> + if (block == NULL)
Jan> + return NULL;
Jan> +
Jan> + func = block_linkage_function (block);
Jan> + if (func == NULL)
Jan> + return NULL;
Just to be sure I understand... in the loop in display_uses_solib_p,
there are two checks:
if (block != NULL
&& solib_contains_address_p (solib, block->startaddr))
return 1;
if (section && section->objfile == solib->objfile)
return 1;
So I gather from this change that the first check is checking for
functions and the second one will handle variables coming from the
solib? And that is why it is ok to replace the first change with
block_objfile? My concern here is that the patch not affect the
semantics of the existing check; and I don't really know the block
stuff very well.
Jan> --- gdb/objfiles.h 15 Jan 2009 16:35:22 -0000 1.59
Jan> +++ gdb/objfiles.h 22 Apr 2009 18:15:45 -0000
Jan> @@ -508,6 +508,7 @@ extern void set_objfile_data (struct obj
Jan> const struct objfile_data *data, void *value);
Jan> extern void *objfile_data (struct objfile *objfile,
Jan> const struct objfile_data *data);
Jan> +extern int matching_objfiles (struct objfile *a, struct objfile *b);
I think this declaration should not be in this section, which is all
related to the objfile_data stuff. Instead just move it above the
comment introducing objfile_data.
Assuming my understanding of the semantics is correct, then this is ok
with the above fixlets. Thanks.
Tom
next prev parent reply other threads:[~2009-04-22 19:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 18:39 Jan Kratochvil
2009-04-22 19:17 ` Tom Tromey [this message]
2009-04-22 20:05 ` Jan Kratochvil
2009-05-25 8:09 ` obsolete: " Jan Kratochvil
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=m31vrkwlaf.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.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