[aspectc-user] Compiler Error - Related Error being fixed in (Version 1.0pre1: 10/2005)?
John C. Weicher
jweicher at piocon.com
Thu Oct 20 18:09:12 CEST 2005
Olaf-
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 definition,
it compiles perfectly (the extern header file issue never occurred to me
though). Do you have any suggestions on a way to get around this without
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 modifying
on their own, have to go in and do the same. Right now the beauty is that
everything is done by a single additional script that I would distribute
with my modification/patch. They'd just have to drop in the distribution,
the scripts calls the aspect compiler to make the changes, calls the apps
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 now
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)?
>
> 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