Re: Fwd: dependency tee from c parser entities downto token

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, May 9, 2012 at 2:48 AM, Konrad Eisele <konrad@xxxxxxxxxxx> 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?


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

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

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.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Newbies FAQ]     [Kernel List]     [Site Home]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Trinity Fuzzer Tool]

Powered by Linux