[aspectc-user] Compiler Error - Related Error being fixed in (Version 1.0pre1: 10/2005)?

[Olaf Spinczyk]

Hi,

there should be no problem, even if the called function (F1 in your 
example) is part of a separate library. The call advice only affects the 
function that calls (F2). You can test it with this example:

void f2 () {
   puts ("hello");
}

int main () {
   f2 ();
}

aspect Foo {
   advice execution("% f2(...)") : before() {
     printf ("before\n");
   }
   advice call("% puts(...)") && within("% f2(...)") : around() {
     tjp->proceed ();
     printf ("after\n");
   }
};

The libc function puts is definitely part of a separate library.

AspectC++ does not generate the function prototype that is missing in 
your case, if

(A) somewhere is a prototype declaration of the wrapped function (f2).
     (in this case the wrapper function prototype will be generated in
     front of this declaration and doesn't have to be generated in front
     of the definition)

(B) the wrapped function is a member function of a class
     (in this case the function is either defined in a class body and,
     thus, declarations are not necessary, or the function is defined
     outside the class body. In this case there will be a declaration
     within the class body and the declaration of the wrapper function
     will be generated there)

Is it possible that there is a declaration of the function f2 (the one 
for which you defined execution advice) in some header file that is 
*not* part of your project (-p option!)? Maybe it is the prototype of a 
different function that unintentionally has the same name. You could try 
to rename your function to rule out this possibility.

- Olaf


John C. Weicher wrote:
> 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
> 
> _______________________________________________
> aspectc-user mailing list
> aspectc-user at aspectc.org
> http://www.aspectc.org/mailman/listinfo/aspectc-user