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

Olaf Spinczyk Olaf.Spinczyk at informatik.uni-erlangen.de
Fri Oct 28 08:59:37 CEST 2005

Hi John,

version 1.0pre1 contains a fix for your problem. I tested it with a 
SystemC application that has had a similar problem.

Of course, I'm interested in your top secret project ;-). Please keep us 


John C. Weicher wrote:
> Olaf-
>   Ha ha ha, please don't think me ungrateful, but I'd rather not say.
> There's some competition on the task, and I'd like to keep our doings to
> ourselves until we're ready to release.  It's always nice to be the first,
> you know?  As for AspectC++, it's been absolutely great.  Up until recently
> our approach was direct modification of existing functions, hacking up the
> original application's source files, etc.  Okay for experimentation, but
> totally unacceptable in the end as a means of producing an external,
> optional patch-like modification, you know?  Then we discovered aspects, and
> it's been great.  So definitely thank you for all your work.  I'll keep you
> posted if you're interested!
> -John
>>-----Original Message-----
>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>Sent: Thursday, October 20, 2005 11:27 AM
>>To: John C. Weicher
>>Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed in
>>(Version 1.0pre1: 10/2005)?
>>on which open source project are you working? How much trouble did you
>>have with AspectC++ so far? ;-)
>>Olaf Spinczyk wrote:
>>>for SystemC there is no solution, yet. We hope simply that no user needs
>>>execution advice for the sc_main function ;-), which is similar to
>>>main() in normaly C++ code.
>>>The best solution would be a last minute fix that is integrated into
>>>version 1.0pre1. I'll do what I can.
>>>John C. Weicher wrote:
>>>>   Dead on!  That is exactly the situation.  And I discovered that
>>>>late last
>>>>night.  If I manually go in and add the declaration before the
>>>>it compiles perfectly (the extern header file issue never occurred to
>>>>though).  Do you have any suggestions on a way to get around this
>>>>the manual intervention? Because everything being open source, it
>>>>would be
>>>>nice to not make potential users who wanted to rebuild the app I'm
>>>>on their own, have to go in and do the same.  Right now the beauty is
>>>>everything is done by a single additional script that I would
>>>>with my modification/patch.  They'd just have to drop in the
>>>>the scripts calls the aspect compiler to make the changes, calls the
>>>>original make routines they would have had to call anyway, and bingo,
>>>>they've modified their app.  I'd love to be able to keep it that way.
>>>>If this is not doable, I'll just have to come up with another
>>>>strategy.  I'm
>>>>sorry I've taken so much of your time on this issue already, as I know
>>>>it's kind of in my court.  But you mentioned another similar encounter,
>>>>SystemC?  What was the solution in that case?
>>>>I really appreciate the help already given.
>>>>>-----Original Message-----
>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>>>Sent: Thursday, October 20, 2005 11:00 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)?
>>>>>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
>>>>>  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
>>>>>front of the definition. Then the execution advice should work as
>>>>>Does that help?
>>>>>John C. Weicher wrote:
>>>>>>  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
>>>>>of my
>>>>>>project directory.  I am using aspects to increase the functionality
>>>>>>module in a much larger open source application.  So like many such
>>>>>>applications, the source code that I am extending is in a separate
>>>>>>the directory tree than the application's main include directory,
>>>>>>the headers for those sources:
>>>>>>-- include  <- prototype for function I'm wrapping in header file
>>>>>>|              (It's an existing application function that I'm
>>>>>>|               not one of my own that I can easily relocate)
>>>>>>-- module   <- where I am placing weaved code to be placed so it can
>>>>>>   |          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
>>>>>>through aspects as modularized from the rest of code as possible (so
>>>>>>be easily applied by interested parties).  I want to avoid having to
>>>>>>changes to files outside of that one 'module' directory (and more
>>>>>>specifically the 'dev') directory.  If possible, I want to avoid
>>>>>>make changes to outside files, for example those in the apps main
>>>>>>directory.  For this same reason, I don't want to rename any function
>>>>>>as the function I am wrapping is actually called from a whole
>>>>>>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
>>>>>>prototype for the function that I am wrapping, which is a point you
>>>>>>about at the end of your last post.
>>>>>>Is it possible to force ac++ to add any necessary new prototypes
>>>>>>the file that contains the source for functions it is
>>>>>>Thanks again for your help.
>>>>>>>-----Original Message-----
>>>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-
>>>>>>>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
>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>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
>>>>>>>your case, if
>>>>>>>(A) somewhere is a prototype declaration of the wrapped function
>>>>>>>   (in this case the wrapper function prototype will be generated in
>>>>>>>   front of this declaration and doesn't have to be generated in
>>>>>>>   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
>>>>>>>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
>>>>>>>>thank you for doing so with your last reply, so that message can at
>>>>>>>>now be included.
>>>>>>>>With that said, unfortunately, I am not sure how to give you a
>>>>>>>>by step, as when I do testing similar to yours, it works for me
>>>>>>>But in
>>>>>>>>doing so, I have found what I think is the source of the problem.
>>>>>>>>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(){
>>>>>>>>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
>>>>>>>>code, I notice a difference between it and the code generated for
>>>>>>>>test.  In the above test, the modifications for the
>>>>>>>>are as follows:
>>>>>>>>#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 ();
>>>>>>>>inline void __exec_old_F2()
>>>>>>>>#line 7 "./main.c"
>>>>>>>>__call__ZN2F2Ev_0_0 ();
>>>>>>>>This makes perfect sense.  We have the prototype for the inline
>>>>>>>>original function, the replacement of the original function which
>>>>>>>>inline alternate, and then the definition of the inline alternate
>>>>>>>>itself has internal modifications due to the other call/around
>>>>>>>>the F1).
>>>>>>>>The kicker is that in my real code, the general layout is the
>>>>>>>>same, but
>>>>>>>>prototype is ever inserted above the replacement of the original
>>>>>>>>There is just the replacement of the original function which calls
>>>>>>>>inline alternate, and then the definition of the inline alternate.
>>>>>>>>the prototype above all this, the undeclared error is going to
>>>>>>>>As I said, other than the above program you gave me, I don't know
>>>>>>>>give you another minimal step by step.  The layout of my real
>>>>>>>>identical.  Can you think of any other reason why a prototype
>>>>>>>>would be
>>>>>>>>Actually I just realized that I have made a mistake.  There is one
>>>>>>>>difference.  The function with the call/around advice (the nested
>>>>>>>>is NOT in the same file as the function causing problems with the
>>>>>>>>prototype.  It's part of another library.  I apologize I missed
>>>>>>>>However, being call/around, the compiler never needs access to it's
>>>>>>>>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
>>>>>>>>function that calls IT.
>>>>>>>>Phew!  Sorry for the long post.  Maybe this will change the
>>>>>>>>>-----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
>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>Thanks for your help so far.  There is really only one difference
>>>>>>>>>my code and your test program.  It's not really a situation of
>>>>>>>>>and before/execution of the same function.  Using your example,
>>>>>>>>>function having advice inserted before its execution is F2(), not
>>>>>>>>>of course have no idea if this should make any difference?
>>>>>>>>>In other words, in your program you have a function F1 that is
>>>>>>>>>called around, as well as having code inserted before its
>>>>>>>>>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
>>>>>>>>>code inserted before it.
>>>>>>>>>I admit even to me this seems like a trivial difference, but you'd
>>>>>>>>>far better.  Could there be a problem with applying before advice
>>>>>>>>>to a
>>>>>>>>>function and then applying around advice to another function call
>>>>>>>>>it? Perhaps simply in how it decides in which order to append
>>>>>>>>>to the source file?  I am totally grasping at straws here.
>>>>>>>>>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
>>>>>>>>>properly generated.  It's just that the code for the alternate
>>>>>>>>>call to
>>>>>>>>>function to handle the before insertion is placed after it's
>>>>>>>>>giving the not defined error when parsed for compling.
>>>>>>>>>Otherwise, all
>>>>>>>>>code is generated perfectly!
>>>>>>>>>Other that this though, nothing else mentioned comes to mind.
>>>>>>>>>your other questions, no, all applicable functions are in the same
>>>>>>>>>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
>>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>>Hi John,
>>>>>>>>>>there is no general problem with around/call and before/execution
>>>>>>>>>>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?
>>>>>>>>>>recursive functions involved? Is f2() declared in a separate
>>>>>>>>>>that does not belong to your project?
>>>>>>>>>>The (HUGE) problem with version 0.9.3 is a different one. It is
>>>>>>>>>>to introductions.
>>>>>>>>>>Best regards,
>>>>>>>>>>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
>>>>>>>>>>>Simplified scenario exists where there is
>>>>>>>>>>>//blah blah
>>>>>>>>>>>//blah blah
>>>>>>>>>>>I have already defined an aspect with advice as follows:
>>>>>>>>>>>advice call("% %someFunctionB(...)") && within("%
>>>>>>>>>>>: around() {  //blah blah }
>>>>>>>>>>>Obviously I am trying to call around function B when called from
>>>>>>>>>>>A (I do some other stuff, and then let it proceed).  This
>>>>>>>>>>>parses, compiles and runs beautifully.  I've been using this in
>>>>>>>>>>>working application for some time now.
>>>>>>>>>>>A new situation has arisen for me now where in addition to the
>>>>>>>>>>>(situation is the same, and the previous advice block is also
>>>>>>>>>>>needed and in place), I ALSO want to define an additional advice
>>>>>>>>>>>to perform some operations before the execution of function A,
>>>>>>>>>>>advice execution("% %someFunctionA(...)") : before() {  // blah
>>>>>>>>>>>This is causing problems.  Weaving still occurs without error,
>>>>>>>>>>>I then try to compile weaved code, I receive the following error
>>>>>>>>>>>(changed the function names to match my fake example above, so
>>>>>>>>>>>: In function `int someFunctionA(args args args.)':
>>>>>>>>>>>:4: `__exec_old_someFunctionA' undeclared (first use this
>>>>>>>>>>>:4: (Each undeclared identifier is reported only once for each
>>>>>>>>>>>appears in.)
>>>>>>>>>>>./thefile.c: In function `int __exec_old_someFunctionA(args arg
>>>>>>>>>>>./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
>>>>>>>>>>>__exec_old_someFunctionA is coming after the modified call to
>>>>>>>>>>>didn't think this mattered with inline functions.
>>>>>>>>>>>I apologize for the lengthy post, but I am definitely
>>>>>>>>>>>confused.  If
>>>>>>>>>>>take the new additional advice block back out, everything
>>>>>>>>>>>I also noticed that although that it specifically mentions only
>>>>>>>>>>>this sounds very similar to the issue that is supposed to be
>>>>>>>>>>>the new release mentioned on the Roadmap page: "fix for the HUGE
>>>>>>>>>>>of ac++ 0.9.3 that causes parse errors, when an aspect defines
>>>>>>>>>>>advice for a class into which it also introduces new
>>>>>>>>>>>Is this the case, and if so is there a workaround in the
>>>>>>>>>>>aspectc-user mailing list
>>>>>>>>>>>aspectc-user at aspectc.org
>>>>>>>>aspectc-user mailing list
>>>>>>>>aspectc-user at aspectc.org
>>>>>>aspectc-user mailing list
>>>>>>aspectc-user at aspectc.org
>>>>aspectc-user mailing list
>>>>aspectc-user at aspectc.org
>>>aspectc-user mailing list
>>>aspectc-user at aspectc.org
> _______________________________________________
> 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