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] |
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] |