[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:22:28 CEST 2005
Olaf-
Well, thank you for your help and time. Don't rush any kind of solution
that you'd rather avoid just for this. For now, I have come up with a sort
of work-around by using some call advice in a slightly different location to
accomplish the tasks. Not the most ideal solution for what I had planned,
but it will definitely suffice for now.
Thank again.
> -----Original Message-----
> From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
> Sent: Thursday, October 20, 2005 11: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,
>
> 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.
>
> Olaf
>
> John C. Weicher wrote:
> > 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
> >
> > _______________________________________________
> > 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