On Tue, May 15, 2012 at 12:52 AM, Konrad Eisele <konrad@xxxxxxxxxxx> 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().
> 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.
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.
You track empty macro pass that one multiple level macro expand 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
