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

[Konrad Eisele <eiselekd@gmail.com>]

On 05/15/2012 11:44 AM, Christopher Li wrote:
> On Tue, May 15, 2012 at 12:52 AM, Konrad Eisele<konrad@gaisler.com>  wrote:
>> The last patch with mdep.c and test-mdep.c was also nothing to
>> apply, only a work in progress to go further...
>
> OK, I mistaken that as apply request. Never mind some of the
> coding style comment then.
>
>> One thing you can see is how I propagate the token sources
>> using:
>>
>> 137:            n->from = list->pos;
>> ...
>> 143:            list->pos.line = id;
>> 144:            list->pos.stream = pps;
>>
>> here you get an argument why it is better to have a
>> (1) ->macro_begin(a)
>>     ->macro_end(b)
>> instead of only one
>> (2) expand_macro(a,b)
>> If you want to use the preprocessorhooks to output human readable macro
>> expansion history line similar to LLVM you probably want a pointer
>> to the "pre-expanded" token location, that is in (a). In (1) you can buildup
>> the token-source-paths going from post-expand buffer (b) through the
>> pre-expanded buffers (a)
>> in (2) you only have the paths going through the expanded buffers, can use
>> (a) to reason
>> about where (b) came from, but  not in a simple way...
>
> At this point I think  1) is actually better for your requirement.
> I start out as hoping the expand_macro() can abstract away the
> internal implementation detail of macro expand and just give you the
> text before and after the macro expand. But with all this extra
> manipulations of the macro tokens, especially the substitute_argument()
> is clear indicate tightening into the implementation details.
>
> I would take 1) over substitute_arguments() if 1) don't need call back like
> substitute_arguments().

substitute_arguments() is because I am not allowed extra token
TOKEN_M_EMPTY. it is unrelated to the upper cases...

>
>
>> Kindof something like this:
>> #define E1
>> #define E2
>> #define S1(a) struct a { E1 int d1; };
>> #define S2(a) struct a { E2 int d2; };
>> #define xdef S1(sx) S2(sy)
>> xdef
>> main() {
>>         struct sx v;
>> }
>>
>> The xdef expands in one-line to "struct sx { int d1; }; struct sy { int d1;
>> };"
>> main() only uses "struct sx". Therefore the dependency analysis should not
>> have "E2 and S2" as dependencies. I think you need the location of empty
>
> That is surprising to me. I previously have different assumptions.
> I assume you want to back trace all the way back to the source macro.
> I would just say main() depend on xdef, which depend one S1 and S2.
> S1 also depend on E1 and S2 depend on E2.

I'm not shure who is wrong here or weather maybe my example is not
general enought, maybe you are right...

>
> If you bypass xdef and directly extract S1(sx). Why can't you do one
> step further bypass S1() as well,  and say main depend on "struct sx {
> E1 int d1;}?
>
> This is even more complicated than I original though.
> How about this case:
>
> #define S1(a) struct a { E1 int d1; }; E3 struct
> #define S2(a) a { E2 int d2; };
>
> The rest is the same. Now xdef will expand to the same text.
> What should main() depend on?  S1, E1 and E3?
> Notice that without S2, macro expand by S1 can't compile at all.
>
>> Do you mean http://cfw.sourceforge.net/htmltag/init_32.c.pinfo.html ? This
>> is a gcc-based patch even there you need to trace empty expansion positions.
>
> Yes. Did that patch submit to gcc? I can see trace empty expansion one level.

Kind-of:-) http://gcc.gnu.org/ml/gcc/2012-03/msg00208.html
It disapears in the gcc list noise however...

> You track empty macro pass that one multiple level macro expand as well?

I dump everything, however I use a perl script to reconstruct...

>
> Chris
>