[aspectc-user] Compiler Error - Related Error being fixed in (Version 1.0pre1: 10/2005)?
John C. Weicher
jweicher at piocon.com
Thu Oct 20 17:01:59 CEST 2005
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
More information about the aspectc-user
mailing list