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: gdb.objc/objcdecode.exp test error..


On Sun, Mar 8, 2009 at 7:10 PM, Matt Rice <ratmice@gmail.com> wrote:
>
> well hmm these only partially fix the issue, still trying to figure
> out how to compile a shared library
> in the testsuite,

Alright so, i've finally gotten around to figuring that out.
Apologies for my lack of brevity.
Attached are testsuite patches which test this, and an additional way
to provoke the issue
I've currently decided to just focus on the assertion failure which is
evident in the current testsuite
and further explored in my tests, and also asked about by Pierre Muller in [1].

The assert was added at [2], this changed the handling in
breakpoint_re_set_one of the return value of decode_line_1 from being
iterated over to asserting that there is only a single value returned.

to quote the gdb manual at [3]:
It is also possible to specify just a method name:

     break create

end quote.

basically the effect of this is that it is possible to create an
ambiguous expression[5]
which is extrapolated into more ambiguous expressions,

e.g. 'create' becomes 'create'
and also '-[Foo create]'
and both 'create' and '-[Foo create]' can also become '-[Foo(bar) create]'
and it is possible for all 3 to exist at the same time.

As Vladimir mentioned on irc this is somewhat non-conventional, e.g.

The c++ language support doesn't do anything like it, e.g.
break create will not expand to Foo::create(void)
and it seems that we have similar behaviour to this already available in rbreak,
but none the less, the behaviour is documented and works _until_ it
hits ambiguity.
e.g. if 'break create' were to match only '-[Bar create]' and '-[Baz
create]', the 2 resulting breakpoints would not be ambiguous nor
trigger the assertion.

Regardless of the above there is a language feature of Objective-C
with which it is possible to also trigger this assertion,  The feature
is called categories, and they are a way in which to add
methods, or override methods,  This situation seems much more akin to
the situation in which breakpoint_re_set_one was intended to handle.

These are tested via the -bar methods in the added .m files.

after loading the Category in libobjcdecode3.so via dlopen, [obj bar];
will call a new implementation, but the symbol was not overridden via
normal c-style linkage, the symbols are unique, so both method
implementations exist, only the objects dispatch table has been
updated, therefore decode_line_1 returns 2 symbols matching the 'bar'
method.  With the criteria that whichever implementation was loaded
last is the one which is used.

because it is rather common for people to cache function pointers to
methods in order to avoid the overhead involved with the dispatch
table lookups, it is a uncommon but possible source of problems to
have a stale cached implementation, so its a good thing we can set a
breakpoint on all implementations of a specific method..

the patch for [5] at [6], will sort of kinda of fix part of these
issues, i've attached a rehashing of it
it will avoid the assertion failures, but it will also fail to
recognize when a category has been loaded and thus fail the "bar
category implementation" tests, so i suppose its better than the
current behaviour.

While the bug listed, mentions going another way about solving said
bug report, it is my opinion that the current assertion failures
cannot be fixed in such a way, only by either removing the assertion,
or avoiding the ambiguity,  though we could always keep the assertion
and split it into 2 stages or something, an ambiguous stage and a
non-ambiguous stage with the assertion.

but there is some weirdness about re-enabling the iteration, for
instance it seems it would cause them to share conditions, i'm not
sure this is wanted in the method/function case, but it probably is in
the method/category method case.

[1]: http://sourceware.org/ml/gdb-patches/2008-03/msg00473.html
[2]: http://sourceware.org/ml/gdb-patches/2007-09/msg00306.html
[3]: info -f gdb --node='Method Names in Commands'
[4]: info -f gdb --node='Ambiguous Expressions'
[5]: http://sourceware.org/bugzilla/show_bug.cgi?id=8343
[6]: http://sourceware.org/bugzilla/show_bug.cgi?id=8535

P.S. the new tests are somewhat duplicated by the original tests I had
done, and the ones from Adam Fedor. I'm guessing that the requirements
of the new ones will probably work on a more limited set of platforms
i suppose, due to the dlopen requirements.  Let me know if you want me
to roll these all into a single test, or if i should keep the old ones
around.

And with regard to 8343, this seems as good a place as any to discuss it,
given that we have up to 2 layers of ambiguity, maybe we need in the
breakpoint structure to differentiate between breakpoints which were
set by the user, and breakpoints which were derived from breakpoints
which are set by the user.

Then we can only ask the user about symbols which can be derived from
user-specified breakpoints, i'm not sure if this would require a
different return value from decode_line_1 or if this should be handled
in the 'break_command_really'.
that way we could avoid asking about '-[Foo(bar) create]' twice when
re_setting both 'create' and '-[Foo create]'. (when using
multiple-symbols ask), also seems like something that could be used
for something akin to a 'pending rbreak'.

P.P.S: these aren't 7.0 regressions they've been around since at least
6.8 in 7.0 we can ignore the assertions specifying 'N', and go about
our debugging where before we would get stuck in a loop with PR #8343
before we got to the assertions.

2009-09-10  Matt Rice  <ratmice@gmail.com>

        * lib/gdb.exp (gdb_continue_to_breakpoint): Fail on internal-error
        instead of falling back to timeout.
        * gdb.objc/objcdecode.exp: Set the multiple symbols found behaviour
        to ask for the original test. Add tests for the multiple symbols
        found behaviour of all.
        * gdb.objc/ambiguous.exp: New tests for ObjC ambiguous expressions
        across shared libraries.
        * gdb.objc/ambiguous.m: Ditto.
        * gdb.objc/objcdecode2.m: Ditto.
        * gdb.objc/objcdecode2.h: Ditto.
        * gdb.objc/objcdecode3.m: Ditto.

Attachment: 0001--lib-gdb.exp-gdb_continue_to_breakpoint.patch
Description: Binary data

Attachment: 0002-Add-enable_ambiguous-argument-to-decode_line_1.patch
Description: Binary data


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