From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17801 invoked by alias); 26 Aug 2011 02:08:40 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 17739 invoked by uid 22791); 26 Aug 2011 02:08:38 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org From: Tom Tromey To: Joel Brobecker Cc: Project Archer Subject: Re: [Archer] update on ambiguous linespec branch References: <20110826014046.GH2851@adacore.com> Date: Fri, 26 Aug 2011 02:08:00 -0000 In-Reply-To: <20110826014046.GH2851@adacore.com> (Joel Brobecker's message of "Thu, 25 Aug 2011 21:40:46 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2011-q3/txt/msg00006.txt.bz2 Tom> * I didn't yet implement the new linespec types, namely allowing Tom> "OBJFILE:" as a prefix, or "FILE:FUNCTION:LINE" or Tom> "FILE:FUNCTION:LABEL". [...] Tom> I don't think this item is really needed for the patch to go in. It Tom> could be done as a follow-up, and IMO would be better that way, since Tom> it will be a second huge change to linespec.c. Joel> On the practical side, I'm wondering how you are going to be able Joel> to implement the case where the user selects a sub-set of all matches Joel> without this part... For instance, if there are two functions called Joel> foobar, and the user types "break foobar", if he selects only to Joel> break on one of them (using the multiple choice menu), how are we Joel> going to support that without the linespec types above? Joel> Or are you thinking of adding support for that as a second step? Right now it works by filtering. A linespec might resolve to multiple locations. Each location has an associated canonical form. The canonical form has overload information and the full symbol name, so e.g., "func" might be "/blah/blah/file.c:func" or "/blah/blah/file.m:+[SomeClass func]". Exactly how these are treated depends on the mode. In multiple-symbols=all, we just make a single breakpoint that matches everything. In multiple-symbols=ask, the menu sorts them by canonical name; this could still result in multiple locations per breakpoint, for example an inlined function has the same canonical form for all locations. When re-setting a breakpoint, the form the user entered ("func") is used to search the symbol tables, but the chosen canonical form (for multiple-symbols=all, NULL; but for multiple-symbols=ask, the particular choice) is used to filter the resulting SALs. Right now the canonical form is not displayed by "info break". This is a flaw. Also, the canonical form cannot always be entered to the "break" command. These are both things that a follow-up series could fix. Currently the canonical form only includes the source file name, if any. So one cannot distinguish functions in different objfiles yet. I'm actually not sure if you really want this -- an inline function may be inlined in multiple objfiles. Also the canonical form for a minimal symbol is just the symbol name (but these are filtered intelligently so you can only have plain "func" mean more than one location you have multiple instances, none of which have debuginfo). Maybe I will just do it all and try to rebase it into submission before submitting. After reading the above it seems like perhaps the best course. I've appended the docs for decode_line_full from the branch. It may help explain how the general replacement for decode_line_1 works. The key missing pieces is that CANONICAL->SALS is a vector of (extended) symtabs_and_lines structures. "break" makes the same number of breakpoints as there are elements in this vector. Tom /* Parse *ARGPTR as a linespec and return results. This is the "full" interface to this module, which handles multiple results properly. FUNFIRSTLINE is nonzero if we want the resulting SALs to describe the first line of indicated functions. DEFAULT_SYMTAB and DEFAULT_LINE describe the default location. DEFAULT_SYMTAB can be NULL, in which case the current symtab and line are used. CANONICAL is where the results are stored. It must not be NULL. SELECT_MODE must be one of the multiple_symbols_* constants, or NULL. It determines how multiple results will be handled. If NULL, the appropriate CLI value will be used. FILTER can either be NULL or a string holding a canonical name. This is only valid when SELECT_MODE is multiple_symbols_all. Multiple results are handled differently depending on the arguments: . With multiple_symbols_cancel, an exception is thrown. . With multiple_symbols_ask, a menu is presented to the user. The user may select none, in which case an exception is thrown; or all, which is handled like multiple_symbols_all, below. Otherwise, CANONICAL->SALS will have one entry for each name the user chose. . With multiple_symbols_all, CANONICAL->SALS will have a single entry describing all the matching locations. If FILTER is non-NULL, then only locations whose canonical name is equal (in the strcmp sense) to FILTER will be returned; all others will be filtered out. */ extern void decode_line_full (char **argptr, int funfirstline, struct symtab *default_symtab, int default_line, struct linespec_result *canonical, const char *select_mode, const char *filter);