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

Olaf Spinczyk Olaf.Spinczyk at informatik.uni-erlangen.de
Thu Oct 20 17:59:54 CEST 2005 

Hi,

I'm slowly beginning to understand (at least I hope so) ...

* you are using ac++ in the WPT mode and not via ag++
* your command line options are "-p module/dev -d module"
* the "include" directory tree does not belong to the project
   (from ac++'s point of view)
* the function for which you define execution advice is
   *declared* somewhere in "include", but defined in your
   part, i.e. module

Is that right? It explains the behavior completely:

* call advice works properly, as the location of the call is part
   of the ac++ project

* execution advice does not work completely, because there is a function
   declaration that does not belong to the ac++ project

We have a similar problem with the SystemC library. In this case the 
function sc_main is declared in a library header file, but the 
implementation has to be provided in the application code.

o check if we are right, you can insert a declaration of the function in 
front of the definition. Then the execution advice should work as expected.

Does that help?

Olaf


John C. Weicher wrote:
> Olaf-
>    As a matter of fact, yes, the prototype for the function that I am
> attempting to call around is included in a header file that is outside of my
> project directory.  I am using aspects to increase the functionality of one
> module in a much larger open source application.  So like many such
> applications, the source code that I am extending is in a separate part of
> the directory tree than the application's main include directory, containing
> the headers for those sources:
> 
> AppRoot
> |
> -- include  <- prototype for function I'm wrapping in header file here
> |              (It's an existing application function that I'm wrapping,
> |               not one of my own that I can easily relocate)
> |
> -- module   <- where I am placing weaved code to be placed so it can still 
>     |          be found by application's existing make routines, etc.
>     |
>     -- dev  <- new directory I've created where I've copied and keep
>                original versions of source and aspects
> 
> The problem is that this is a large application, to which I am trying to
> develop a useful extension to that I could offer to people.  I'm only
> mentioning all this because the point is I want to keep my modifications
> through aspects as modularized from the rest of code as possible (so it can
> be easily applied by interested parties).  I want to avoid having to make
> changes to files outside of that one 'module' directory (and more
> specifically the 'dev') directory.  If possible, I want to avoid having to
> make changes to outside files, for example those in the apps main include
> directory.  For this same reason, I don't want to rename any function names
> as the function I am wrapping is actually called from a whole different
> module, which means I'd have to edit IT'S code as well, etc.
> 
> I assume this is causing my problem, because there is then an existing
> prototype for the function that I am wrapping, which is a point you asked
> about at the end of your last post.  
> 
> Is it possible to force ac++ to add any necessary new prototypes right into
> the file that contains the source for functions it is weaving/modifying?
> 
> Thanks again for your help.
>  
>  
>  
>>-----Original Message-----
>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>Sent: Thursday, October 20, 2005 3:16 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,
>>
>>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
> 
> _______________________________________________
> 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