From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: jan.kratochvil@redhat.com (Jan Kratochvil)
Cc: ratmice@gmail.com (Matt Rice),
brobecker@adacore.com (Joel Brobecker),
gdb-patches@sourceware.org
Subject: [rfc] Move PC in-range check in objc-lang.c:find_methods (Re: [ia64] Regression)
Date: Tue, 29 Sep 2009 17:27:00 -0000 [thread overview]
Message-ID: <200909291727.n8THRdfW031402@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20090929154328.GA15183@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Sep 29, 2009 05:43:28 PM
Jan Kratochvil wrote:
> mst_data looks suspicious but on ppc64 case the function descriptor has really
> mst_data there:
Looking at the location in objc-lang.c:find_methods where the mst_text
check used to be a bit closer, I noticed something odd anyway:
ALL_OBJFILE_MSYMBOLS (objfile, msymbol)
{
struct gdbarch *gdbarch = get_objfile_arch (objfile);
CORE_ADDR pc = SYMBOL_VALUE_ADDRESS (msymbol);
QUIT;
/* The minimal symbol might point to a function descriptor;
resolve it to the actual code address instead. */
pc = gdbarch_convert_from_func_ptr_addr (gdbarch, pc,
¤t_target);
if (symtab)
if (pc < BLOCK_START (block) || pc >= BLOCK_END (block))
/* Not in the specified symtab. */
continue;
symname = SYMBOL_NATURAL_NAME (msymbol);
if (symname == NULL)
continue;
if ((symname[0] != '-' && symname[0] != '+') || (symname[1] != '['))
/* Not a method name. */
continue;
while ((strlen (symname) + 1) >= tmplen)
{
tmplen = (tmplen == 0) ? 1024 : tmplen * 2;
tmp = xrealloc (tmp, tmplen);
}
strcpy (tmp, symname);
if (parse_method (tmp, &ntype, &nclass, &ncategory, &nselector) == NULL)
continue;
objfile_csym++;
For every msymbol in the objfile, the very *first* check is whether
its address is in range of the given symbol table. Only then come the
checks against the symbol name up to and including the parse_method call.
If those checks pass, the objfile_csym count is increased.
However, that count is supposed to be the number of *all* ObjC symbols
in the objfile, not just those that match the given symtab. Note the
sanity check at the end:
/* Count of ObjC methods in this objfile should be constant. */
gdb_assert (*objc_csym == objfile_csym);
It would appear that if find_methods is first called with a non-NULL
symtab, objfile_csym is set to the number of ObjC symbols within that
symtab. Assuming this is non-zero, and find_methods is later called
with a different (or NULL) symtab value, the loop will now possibly
compute a *different* count of ObjC symbols, triggering the assertion.
Therefore, it seems that the range check against the symtab ought
to be performed only *after* the symbol name checks are done and
objfile_csym is incremented ...
As a side effect, this would also reduce the number of calls to
gdbarch_convert_from_func_ptr_addr for symbols that clearly are not
ObjC symbols, reducing the potential of running into problems in
targets that cannot deterministically tell whether an address
points to a function descriptor or not.
This is implemented by the following patch. Does this look
reasonable?
Tested on ppc(64)-linux with no regressions.
Bye,
Ulrich
ChangeLog:
* objc-lang.c (find_methods): Move function descriptor conversion
and PC in-range check until after basic checks for ObjC symbols.
Index: gdb/objc-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/objc-lang.c,v
retrieving revision 1.84
diff -c -p -r1.84 objc-lang.c
*** gdb/objc-lang.c 29 Sep 2009 00:48:31 -0000 1.84
--- gdb/objc-lang.c 29 Sep 2009 17:11:19 -0000
*************** find_methods (struct symtab *symtab, cha
*** 1178,1193 ****
QUIT;
- /* The minimal symbol might point to a function descriptor;
- resolve it to the actual code address instead. */
- pc = gdbarch_convert_from_func_ptr_addr (gdbarch, pc,
- ¤t_target);
-
- if (symtab)
- if (pc < BLOCK_START (block) || pc >= BLOCK_END (block))
- /* Not in the specified symtab. */
- continue;
-
symname = SYMBOL_NATURAL_NAME (msymbol);
if (symname == NULL)
continue;
--- 1178,1183 ----
*************** find_methods (struct symtab *symtab, cha
*** 1208,1213 ****
--- 1198,1213 ----
objfile_csym++;
+ /* The minimal symbol might point to a function descriptor;
+ resolve it to the actual code address instead. */
+ pc = gdbarch_convert_from_func_ptr_addr (gdbarch, pc,
+ ¤t_target);
+
+ if (symtab)
+ if (pc < BLOCK_START (block) || pc >= BLOCK_END (block))
+ /* Not in the specified symtab. */
+ continue;
+
if ((type != '\0') && (ntype != type))
continue;
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2009-09-29 17:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-27 21:49 [rfc] Fix Obj-C method calls on 64-bit PowerPC Ulrich Weigand
2009-09-28 17:51 ` Joel Brobecker
2009-09-28 22:41 ` Matt Rice
2009-09-29 0:50 ` Ulrich Weigand
2009-09-29 15:44 ` [ia64] Regression: " Jan Kratochvil
2009-09-29 16:07 ` Ulrich Weigand
2009-09-29 16:17 ` Jan Kratochvil
2009-09-29 16:16 ` Joel Brobecker
2009-09-29 16:30 ` Jan Kratochvil
2009-09-29 16:40 ` Joel Brobecker
2009-09-29 19:11 ` Jan Kratochvil
2009-09-29 16:45 ` Ulrich Weigand
2009-09-29 19:07 ` [commit] Avoid Obj-C test timeouts due to symbols not found Ulrich Weigand
2009-09-29 17:27 ` Ulrich Weigand [this message]
2009-09-29 17:46 ` [rfc] Move PC in-range check in objc-lang.c:find_methods (Re: [ia64] Regression) Joel Brobecker
2009-09-29 21:08 ` [ia64] Regression: Re: [rfc] Fix Obj-C method calls on 64-bit PowerPC 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=200909291727.n8THRdfW031402@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=ratmice@gmail.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