[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 18:16:17 CEST 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