From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Eisele Subject: Re: Fwd: dependency tee from c parser entities downto token Date: Thu, 10 May 2012 08:38:32 +0200 Message-ID: <4FAB6268.7070908@gaisler.com> References: <4F967865.60809@gaisler.com> <4FA3B14A.3070609@gaisler.com> <4FA44E3D.6020504@gmail.com> <4FA4EAD6.1040206@gmail.com> <4FA5B9E8.7010208@gmail.com> <4FA767BD.8060703@gaisler.com> <4FA8BF7D.60606@gaisler.com> <4FAA3D50.8080901@gaisler.com> <4FAB5DEA.5060009@gaisler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail176c2.megamailservers.com ([69.49.111.76]:33735 "EHLO mail176c2.megamailservers.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756301Ab2EJGsm (ORCPT ); Thu, 10 May 2012 02:48:42 -0400 In-Reply-To: <4FAB5DEA.5060009@gaisler.com> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Christopher Li Cc: Konrad Eisele , Linux-Sparse Konrad Eisele wrote: > Christopher Li wrote: >> On Wed, May 9, 2012 at 2:48 AM, Konrad Eisele wrote: >>> I dont think its practical: If you have a argument that is expanded then >>> when using 4 callbacks you get the calls: >>> >>> arg-expand-begin(a) >>> body-expand-begin(c) >>> body-expand-end(d) >>> arg-expand-end(b) >>> >>> When using 2 callbacks you get the calls: >>> >>> body-expand(c d) >>> arg-expand-begin(a b) >>> >>> But "a" is the source to both "c" and "d". The goal of all this is to >>> generate a tree. You need to know where a token originated from. The >>> tokens in "a" might be duplicated, then in your case you dont have >>> enough information to reason about the origin of "c". >> >> I was thinking that you can use the sym->parent to find out you are inside >> which macro's scope. If I change the sym->parent to the token type, which >> is the token initiated the macro expand. Then you should have all the >> information >> you need? > > You dont get the point. Is there a pointer token.parent? No. How can > you know which macro expansion you _came from_, you only know > where you _end up_. How can you build the _branches_ of a tree? You can > only build _leafs_. > Funny thing is: When you _are_ a commiter you _can_ suddenly add > "sym.parent" when you think it is necessary? All this mess is originally > because you dont think that sym.token can replace sym.position... > Wasnt adding new members a sin ? I guess it actually doesnt matter, > if you are a committer ...:-) > >> >> >>> I do it like this: Inside >>> arg-expand-begin(a) I "dope" all tokens of "a" by setting >>> token.pos.position (which I understood I can use as I want) >>> with an unique id (token.pos.stream is my preprocessor stream). When a >>> token is duplicated in argument replacement etc. token.pos will also >>> be copied. The duplicates of "a" will always retain information where >>> they came from. >>> Then I can regenerate the tree. >> >> Right, you can still do the the duping with expand_macro call back. >> >>> T think you need to implement this first so that I can see how it could >>> be done... >> >> That will take more time. I am hoping you can point out what is missing >> in the demo program. Which you did already. > > Apply my latest patch any you'll see. > > Also: I dont see that you do anything with token.pos. Dont > you remember that you came up with token.pos encoding to avoid adding > a new member to token that my original patch did? > In the last patch I sent this idea is used, as described, I write > an unique id to token.pos.position that then shows the origin... > You seem to have forgotten what we started from. > >> >>>> I still haven't fully understand why you need the empty token type. >>>> However >>>> there is the untaint token which mark the end of the a macro expand. You >>>> might able to use that as well. >>> >>> >>> I dont think you can, not without patching preprocess.c. And the patching >>> would be messier than by introducing a dedicated token. >>> Also: TOKEN_M_EMPTY is only used by the hook, it is also >>> removed afterwards >> >> I can only guess how to TOKEN_M_EMPTY in the call back. I only >> see the code add into into the stream and removed, not how the client >> use it. >> >> Here is another idea. Instead of require the client to register a lot of >> callback function. We can have option to insert macro expand annotation token >> into the token stream. The annotation token mark the beginning and end of the >> macro expansion. In the macro begin annotation, it will preserve the >> original stream >> before the expansion. Similarly, there will be begin and end >> annotation for the argument >> replacement. > > This is all the same thing. It doenst matter how, just implement it. > I dont understand: Here you think you can patch 1000 lines in the > original code (which your new idea would requite ) however you > insist of 2 callbacks (callbacks that normal code would ignore anyway) > because you dont want to grant me 4 extra lines (the begin-end hooks+define+post). > This is greedy at least, I dont get it, I think I'm out of here... > >> >> The client can do a custom pass to consume the annotation token. It should >> be able to build the patch tree that lead to the expansion result. The >> annotation >> token will be consume and removed from the token stream before it get pass to >> the parser. Reading it 2 times and thinking about what kind of thought drive you: I can only say this is fucking sick: You oppose adding one little TOKEN_M_EMPTY, now you use my idea to add 100 new tokens and yeah ... Hello, hello ... How can you filter them out : You _cannot_ add a "post" hook. :-) Haha... > > Have fun implementing it :-) > -- Konrad > >> >> In this way, no call back is required. It is all data structures. The >> comments of >> the source code can fit nicely into the annotation token as well. >> >> Chris >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sparse" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >