[aspectc-user] Compiler Error - Related Error being fixed in (Version 1.0pre1: 10/2005)?
John C. Weicher
jweicher at piocon.com
Wed Oct 19 17:50:00 CEST 2005
I apologize for not CC-ing my first response to the listserv as well, so
thank you for doing so with your last reply, so that message can at least
now be included.
With that said, unfortunately, I am not sure how to give you a minimal step
by step, as when I do testing similar to yours, it works for me too! But in
doing so, I have found what I think is the source of the problem. There is
in fact a prototype that is being omitted from the weaved code.
Using the following example, all but identical to yours:
void F1(){
}
void F2(){
F1();
}
int main(int argc, char **argv){
F2();
return 0;
}
aspect intercept{
advice call("% F1(...)") && within("% F2(...)") : around() {
printf("About to enter F1()\n");
tjp->proceed();
}
advice execution("% F2(...)") : before() {
printf("About to enter F2\n");
}
};
--
Everything here works just fine. But when I go back and look at my actual
code, I notice a difference between it and the code generated for the above
test. In the above test, the modifications for the execution/before advice
are as follows:
<snip>
#line 7 "./main.c"
#line 1 ""
inline void __exec_old_F2();
#line 7 "./main.c"
void F2()
#line 1 ""
{
AC::invoke_intercept_intercept_a1_before ();
__exec_old_F2();
}
inline void __exec_old_F2()
#line 7 "./main.c"
{
__call__ZN2F2Ev_0_0 ();
}
<snip>
This makes perfect sense. We have the prototype for the inline altered
original function, the replacement of the original function which calls the
inline alternate, and then the definition of the inline alternate (which
itself has internal modifications due to the other call/around advice for
the F1).
The kicker is that in my real code, the general layout is the same, but NO
prototype is ever inserted above the replacement of the original function.
There is just the replacement of the original function which calls the
inline alternate, and then the definition of the inline alternate. Without
the prototype above all this, the undeclared error is going to occur.
As I said, other than the above program you gave me, I don't know how to
give you another minimal step by step. The layout of my real project is
identical. Can you think of any other reason why a prototype would be
omitted?
Actually I just realized that I have made a mistake. There is one
difference. The function with the call/around advice (the nested function)
is NOT in the same file as the function causing problems with the missing
prototype. It's part of another library. I apologize I missed this.
However, being call/around, the compiler never needs access to it's actual
code, correct?, and in fact I wasn't having any problems with it's
call/around advice anyway, until I added the execute/before advice to the
function that calls IT.
Phew! Sorry for the long post. Maybe this will change the situation?
> -----Original Message-----
> From: John C. Weicher [mailto:jweicher at piocon.com]
> Sent: Wednesday, October 19, 2005 9:13 AM
> To: 'Olaf Spinczyk'
> Subject: RE: [aspectc-user] Compiler Error - Related Error being fixed in
> (Version 1.0pre1: 10/2005)?
>
> Thanks for your help so far. There is really only one difference between
> my code and your test program. It's not really a situation of around/call
> and before/execution of the same function. Using your example, the
> function having advice inserted before its execution is F2(), not F1(). I
> of course have no idea if this should make any difference?
>
> In other words, in your program you have a function F1 that is both being
> called around, as well as having code inserted before its execution
> contents.
>
> In my code I have a function F1 that is being called around, and a
> _different_ function (from which the first is called), that is having the
> code inserted before it.
>
> I admit even to me this seems like a trivial difference, but you'd know
> far better. Could there be a problem with applying before advice to a
> function and then applying around advice to another function call within
> it? Perhaps simply in how it decides in which order to append weaved code
> to the source file? I am totally grasping at straws here. Obviously the
> operations of the weaver are way over my head. It's just that the odd
> thing is, if I go look at the source file, all the code for all advices is
> properly generated. It's just that the code for the alternate call to the
> function to handle the before insertion is placed after it's invocation,
> giving the not defined error when parsed for compling. Otherwise, all the
> code is generated perfectly!
>
> Other that this though, nothing else mentioned comes to mind. Regarding
> your other questions, no, all applicable functions are in the same source
> file, and no recursion is involved.
>
> Thanks for your help.
>
>
>
>
> > -----Original Message-----
> > From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
> > Sent: Wednesday, October 19, 2005 2:25 AM
> > To: John C. Weicher
> > Cc: aspectc-user at aspectc.org
> > Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed
> in
> > (Version 1.0pre1: 10/2005)?
> >
> > Hi John,
> >
> > there is no general problem with around/call and before/execution advice
> > for the same function. I tried the following example without any
> > problems (version 0.9.3):
> >
> > --
> > void f1 () {
> > }
> >
> > void f2 () {
> > f1 ();
> > }
> >
> > int main () {
> > f2 ();
> > }
> >
> > aspect Foo {
> > advice call("% f1(...)") && within("% f2(...)") : around() {
> > tjp->proceed ();
> > printf ("after\n");
> > }
> > advice execution("% f1(...)") : before() {
> > printf ("before\n");
> > }
> > };
> > --
> >
> > What is the difference between your code and this test program? Are any
> > recursive functions involved? Is f2() declared in a separate header file
> > that does not belong to your project?
> >
> > The (HUGE) problem with version 0.9.3 is a different one. It is related
> > to introductions.
> >
> > Best regards,
> >
> > Olaf
> >
> >
> > John C. Weicher wrote:
> > > I am running into an odd error during compilation that only crops up
> > > when I provide two separate advice calls which affect the same
> function.
> > >
> > >
> > >
> > > Simplified scenario exists where there is
> > >
> > >
> > >
> > > someFunctionA(){
> > >
> > >
> > >
> > > //blah blah
> > >
> > >
> > >
> > > someFunctionB();
> > >
> > >
> > >
> > > //blah blah
> > >
> > > }
> > >
> > >
> > >
> > > I have already defined an aspect with advice as follows:
> > >
> > >
> > >
> > > advice call("% %someFunctionB(...)") && within("%
> %someFunctionA(...)")
> > > : around() { //blah blah }
> > >
> > >
> > >
> > > Obviously I am trying to call around function B when called from
> within
> > > A (I do some other stuff, and then let it proceed). This weaves,
> > > parses, compiles and runs beautifully. I've been using this in a
> > > working application for some time now.
> > >
> > >
> > >
> > > A new situation has arisen for me now where in addition to the above
> > > (situation is the same, and the previous advice block is also still
> > > needed and in place), I ALSO want to define an additional advice block
> > > to perform some operations before the execution of function A, done as
> > > follows:
> > >
> > >
> > >
> > > advice execution("% %someFunctionA(...)") : before() { // blah blah }
> > >
> > >
> > >
> > > This is causing problems. Weaving still occurs without error, but
> when
> > > I then try to compile weaved code, I receive the following error
> > > (changed the function names to match my fake example above, so it
> makes
> > > sense):
> > >
> > >
> > >
> > > : In function `int someFunctionA(args args args.)':
> > >
> > > :4: `__exec_old_someFunctionA' undeclared (first use this function)
> > >
> > > :4: (Each undeclared identifier is reported only once for each
> function
> > it
> > >
> > > appears in.)
> > >
> > > ./thefile.c: In function `int __exec_old_someFunctionA(args arg
> args)':
> > >
> > > ./thefile.c:280: `int __exec_old_someFunctionA(args args args)
> > >
> > > ' used prior to declaration
> > >
> > >
> > >
> > > And sure enough, when I go into the file the inline definition for
> > > __exec_old_someFunctionA is coming after the modified call to it. But
> I
> > > didn't think this mattered with inline functions.
> > >
> > >
> > >
> > > I apologize for the lengthy post, but I am definitely confused. If I
> > > take the new additional advice block back out, everything compiles
> fine
> > > again.
> > >
> > >
> > >
> > > I also noticed that although that it specifically mentions only
> classes,
> > > this sounds very similar to the issue that is supposed to be fixed in
> > > the new release mentioned on the Roadmap page: "fix for the HUGE
> problem
> > > of ac++ 0.9.3 that causes parse errors, when an aspect defines code
> > > advice for a class into which it also introduces new
> functions/members".
> > >
> > >
> > >
> > > Is this the case, and if so is there a workaround in the meantime?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> --
> > >
> > > _______________________________________________
> > > aspectc-user mailing list
> > > aspectc-user at aspectc.org
> > > http://www.aspectc.org/mailman/listinfo/aspectc-user
More information about the aspectc-user
mailing list