On 05/15/2012 11:44 AM, Christopher Li wrote:
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().
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
--
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
