Hi, Thank you both. The answers are very helpful. I have tried the __attribute__ ((noinline)) - and it works fine.
Thanks again, Arik On Wed, Feb 10, 2010 at 13:07, Giuseppe Cardone < [email protected]> wrote: > Hi, > > you are looking in the right place. Probably you can not see your > functions because gcc inlines them for performance and code size > issues (the balance between the two is actually a complicate matter, > so let's just skip the details - > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Inline.html ). What ncc > does is actually to translate all the nesC code into a big C code, > app.c . Since C has not namespaces it mangles the function names to > avoid name clashing. The schema it uses is: > componentname__interfacename__eventorfunctionname. Let's take for a > sample code-hunting session the Blink application. The event > Timer0.fired() in the Blink application is translated into > BlinkC__Timer0__fired() . If you look for it in > build/yourplatforname/app.c you'll see that it is declared as: > > static inline void BlinkC__Timer0__fired(void ) > > The "inline" keyword means that the compiler will evaluate the > possibility to substitute the code of the function into its caller. In > the case of BlinkC__Timer0__fired you'll see that it is called only by > the VirtualizeTimerC__0__Timer__fired(), so is highly probable that > the compiler will find the inlining profitable both in terms of code > size and speed. But VirtualizeTimerC__0__Timer__fired is inlineable > itself, and is called by VirtualizeTimerC__0__fireTimers(uint32_t now) > (which is not declared as inline). This is the function name that you > can find using msp430-objdump. If you try to dump main.exe for the > blink application you'll see that the > VirtualizeTimerC__0__Timer__fired is inlined into > VirtualizeTimerC__0__fireTimers, and its assembly code is (snipped): > > 46fa: 4f 4b mov.b r11, r15 > 46fc: 1f 93 cmp #1, r15 ;r3 As==01 > 46fe: 0e 24 jz $+30 ;abs 0x471c > 4700: 2f 93 cmp #2, r15 ;r3 As==10 > 4702: 03 34 jge $+8 ;abs 0x470a > 4704: 0f 93 tst r15 > 4706: 04 24 jz $+10 ;abs 0x4710 > 4708: 1b 3c jmp $+56 ;abs 0x4740 > 470a: 2f 93 cmp #2, r15 ;r3 As==10 > 470c: 0d 24 jz $+28 ;abs 0x4728 > 470e: 18 3c jmp $+50 ;abs 0x4740 > 4710: b0 12 42 40 call #0x4042 > 4714: f2 e0 10 00 xor.b #16, &0x0031 ;#0x0010 > 4718: 31 00 > 471a: 0b 3c jmp $+24 ;abs 0x4732 > 471c: b0 12 42 40 call #0x4042 > 4720: f2 e0 20 00 xor.b #32, &0x0031 ;#0x0020 > 4724: 31 00 > 4726: 05 3c jmp $+12 ;abs 0x4732 > 4728: b0 12 42 40 call #0x4042 > 472c: f2 e0 40 00 xor.b #64, &0x0031 ;#0x0040 > 4730: 31 00 > 4732: b0 12 56 40 call #0x4056 > > The code that turns on and off the leds is: > > 4710: b0 12 42 40 call #0x4042 > 4714: f2 e0 10 00 xor.b #16, &0x0031 ;#0x0010 > 4718: 31 00 > 471a: 0b 3c jmp $+24 ;abs 0x4732 > 471c: b0 12 42 40 call #0x4042 > 4720: f2 e0 20 00 xor.b #32, &0x0031 ;#0x0020 > 4724: 31 00 > 4726: 05 3c jmp $+12 ;abs 0x4732 > 4728: b0 12 42 40 call #0x4042 > 472c: f2 e0 40 00 xor.b #64, &0x0031 ;#0x0040 > 4730: 31 00 > 4732: b0 12 56 40 call #0x4056 > > (the calls to #0x4042 and #0x4056 respectively begin and and an atomic > section). So you may not find your function name when you dump the > assembled file, but your code is still there ;) > > Hope this helps. > > Regards > > -- > Giuseppe Cardone > > > > On Wed, Feb 10, 2010 at 9:34 AM, Arik Sapojnik <[email protected]> wrote: > > Hey, > > > > I have generated assembly code by running "msp430-objdump -D main.exe". > > But I don't see any of my functions there. > > Where can I see my code? > > > > -- > > Best Regards, > > Arik Sapojnik > > > > > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > -- Best Regards, Arik Sapojnik [email protected]
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
