Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Getting the size of a C function

Reply
Thread Tools

Getting the size of a C function

 
 
jacob navia
Guest
Posts: n/a
 
      01-23-2010
Mark Borgerson a écrit :
> In article <(E-Mail Removed)>,
> http://www.velocityreviews.com/forums/(E-Mail Removed) says...
>> On Fri, 22 Jan 2010 22:53:18 +0000, john wrote:
>>
>>> I need to know the size of a function or module because I need to
>>> temporarily relocate the function or module from flash into sram to
>>> do firmware updates.

>> Do you need to be able to run it from RAM? If so, simply memcpy()ing it
>> may not work. And you would also need to copy anything which the function
>> calls (just because there aren't any explicit function calls in the source
>> code, that doesn't mean that there aren't any in the resulting object code).
>>
>>

> At the expense of a few words of code and a parameter, you could do
>
>
> int MoveMe(...., bool findend){
> if(!findend){
>
> // do all the stuff the function is supposed to do
>
> } else Markend();
>
> }
>
>
> Where Markend is a function that pulls the return
> address off the stack and stashes it somewhere
> convenient. Markend may have to have some
> assembly code. External code can then
> subtract the function address from the address
> stashed by Markend(), add a safety margin, and
> know how many bytes to move to RAM.
>
>
> Mark Borgerson
>


Sorry Mark but this is totally WRONG!

The return address contains the address where the CPU RETURNS TO
when the current function is finished, not the end of the
current function!!!

The return address will be in the middle of another function, that CALLED
this one.
 
Reply With Quote
 
 
 
 
Stefan Reuther
Guest
Posts: n/a
 
      01-23-2010
john wrote:
> I need to know the size of a function or module because I need to
> temporarily relocate the function or module from flash into sram to
> do firmware updates.
>
> How can I determine that at runtime?


You can't in standard C, because functions are not contiguous objects.

Most environments have some way of placing a function in a special
section (using pragmas or things like __attribute__), and a possibility
to acquire position and size of that section (using linker magic).

In general, you cannot assume a function generates just a single blob of
assembly code in the ".text" sections. For example, functions containing
string or floating-point literals, or large switches, often generate
some data in ".rodata", static variables end up in ".data" or ".bss",
and if you're doing C++, you'll get some exception handling tables as well.


Stefan

 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      01-23-2010
jacob navia wrote:
> john a écrit :
>> Hi,
>>
>> I need to know the size of a function or module because I need to
>> temporarily relocate the function or module from flash into sram to
>> do firmware updates.
>>
>> How can I determine that at runtime? The
>> sizeof( myfunction)
>> generates an error: "size of function unknown".
>>
>> Thanks.

>
> (1)


<snip lots of methods>

> Method (4) needs a disassembler, and a LOT of parsing work,
> and it is very sensitive to compilation options.


You forgot to mention the method which, in my experience, is by far the
best, most reliable, and easiest method.

Read the manual!

This is NOT a glib suggestion, on the one occasion where I needed to do
something similar, but for different reasons, I read the manual and low
and behold the implementation documented a nice and relatively easy way
to achieve when I wanted. In fact, using any other method was almost
guaranteed to produce a function that did not work correctly. After all,
there could be references to absolute addresses which will be wrong
after the code is moved!

In my case, it was compile the function and get it in to a specific
section (I can't remember how now) and then tell the linker to locate
the section at one location for programming in to the ROM but set up all
the addresses as if it would be placed in another section. Then use some
link-time constants (can't remember the details) for moving it. As I
say, it was all fully documented in the manuals!

There is every chance that someone on comp.arch.embedded might know how
to do it on the target platform, if the OP specifies the target platform.
--
Flash Gordon
 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      01-23-2010

"Grant Edwards" <(E-Mail Removed)> wrote in message
news:hjdjjj$njp$(E-Mail Removed)...
> On 2010-01-23, BGB / cr88192 <(E-Mail Removed)> wrote:
>
>> in this case, it might actually be better advised to generate the
>> function
>> as a chunk of arch-specific ASM or machine code (ASM is preferable IMO,
>> but
>> requires an assembler...), which could then be located wherever (such as
>> the
>> heap).

>
> IMO, the "right" thing to do is to tell the compiler to put the
> function into a separate section and then have it linked so
> that it's "located" to run in RAM at the proper address but
> stored in ROM.
>
> That way you know the code will work correctly when it's run
> from RAM. Defining approprate symbols in the linker command
> file will allow the program to refer to the start and end of
> the section's address in ROM.
>


this is a little closer to the second option, of having a secondary image
file embedded as data...


> The OP needs to spend some time studying the manuals for his
> compiler and linker.
>


this is, assuming the linker or image format actually supports the "separate
section" idea...

dunno about ELF, but PE/COFF would not support this, since it would require
breaking some of the internal assumptions of the file format (for example,
that the image is continuous from ImageBase to ImageBase+ImageSize, ...).

ELF may have similar restrictions (actually, I think most ELF images are
position independent anyways, so one could relocate and adjust the GOT for
an image easily enough).

(note that embedding an additional PE/COFF of ELF image would not likely be
"that difficult", and the formats are not particularly difficult to work
with).
a fixed-address PE/COFF image is likely an easy case, since one can copy the
contents of the sections and then call into it.

for fixed-address, producing a raw binary image (supported by GNU ld, ...)
is also probably a good option, since in this case the resulting image can
be copied as a raw chunk of data (no need to relocate or worry about
file-format), and jumped into.


can't say so much about other file formats though...


 
Reply With Quote
 
James Harris
Guest
Posts: n/a
 
      01-23-2010
On 23 Jan, 08:03, jacob navia <(E-Mail Removed)> wrote:

....

> > At the expense of a few words of code and a parameter, you could do

>
> > int MoveMe(...., bool findend){
> > * *if(!findend){

>
> > * *// do all the stuff the function is supposed to do

>
> > * *} else Markend();

>
> > }

>
> > Where Markend is a function that pulls the return
> > address off the stack and stashes it somewhere
> > convenient.


....

> Sorry Mark but this is totally WRONG!
>
> The return address contains the address where the CPU RETURNS TO
> when the current function is finished, not the end of the
> current function!!!


So in Mark's example what will it be in Markend()?

> The return address will be in the middle of another function, that CALLED
> this one.


i.e. Moveme()?

James
 
Reply With Quote
 
Mark Borgerson
Guest
Posts: n/a
 
      01-23-2010
In article <hjeah3$10g$(E-Mail Removed)>, (E-Mail Removed) says...
> Mark Borgerson a écrit :
> > In article <(E-Mail Removed)>,
> > (E-Mail Removed) says...
> >> On Fri, 22 Jan 2010 22:53:18 +0000, john wrote:
> >>
> >>> I need to know the size of a function or module because I need to
> >>> temporarily relocate the function or module from flash into sram to
> >>> do firmware updates.
> >> Do you need to be able to run it from RAM? If so, simply memcpy()ing it
> >> may not work. And you would also need to copy anything which the function
> >> calls (just because there aren't any explicit function calls in the source
> >> code, that doesn't mean that there aren't any in the resulting object code).
> >>
> >>

> > At the expense of a few words of code and a parameter, you could do
> >
> >
> > int MoveMe(...., bool findend){
> > if(!findend){
> >
> > // do all the stuff the function is supposed to do
> >
> > } else Markend();
> >
> > }
> >
> >
> > Where Markend is a function that pulls the return
> > address off the stack and stashes it somewhere
> > convenient. Markend may have to have some
> > assembly code. External code can then
> > subtract the function address from the address
> > stashed by Markend(), add a safety margin, and
> > know how many bytes to move to RAM.
> >
> >
> > Mark Borgerson
> >

>
> Sorry Mark but this is totally WRONG!
>
> The return address contains the address where the CPU RETURNS TO
> when the current function is finished, not the end of the
> current function!!!
>
> The return address will be in the middle of another function, that CALLED
> this one.


I think you missed a few points:

Inside Markend, The return address on the stack will be the address
after the call to Markend----which was purposely located at the end of
MoveMe. Then next few instructions after the call to
Markend will be the return from MoveMe (an RTS or equivalent with stack
cleanup).


Inside Markend, the return address on the stack will be
an address near the end of MoveMe. It is that address that
you need to save and make available for the computation
of the function length.

In assembly, the code in Moveme might look like this:

0900 MoveMe: sub.l #8, SP // make room for 8 bytes of locals
0904 test.l R14 // check the findend parameter in R14
0908 bne lbl1; // if true, just find end of function
.....
..... // all the work of Moveme goes here
..... // and gets executed when findend is zero
.....
1000 bra lbl2 // skip the markend call
1004 lbl1: bsr Markend
1008 lbl2: add.l #8, SP // clean up 8 bytes of local variables
1012 rts // return from MoveMe

When Markend is called at 1004, the address 1008 gets pushed on the
stack.

Inside Markend, you could do:

2040 Markend: Move SP, NearEnd // NearEnd is a global variable
2044 RTS

Someplace else, could do

MMLength = NearEnd - (unsigned long)&Moveme + 4;


When I was teaching introductory M68K assembly language, I used
to give exam problems with nested subroutine calls like this---some
with pushed local variables, and ask the students to show
the contents of the stack at some point in the function.
Those questions really separated the As from the Bs and
Cs!

NOTE: You have to make sure that your compiler doesn't convert
the Markend function to an inline sequence of instructions.


Mark Borgerson

 
Reply With Quote
 
Mark Borgerson
Guest
Posts: n/a
 
      01-23-2010
In article <(E-Mail Removed)>, (E-Mail Removed)
says...
> john wrote:
> > I need to know the size of a function or module because I need to
> > temporarily relocate the function or module from flash into sram to
> > do firmware updates.
> >
> > How can I determine that at runtime?

>
> You can't in standard C, because functions are not contiguous objects.
>
> Most environments have some way of placing a function in a special
> section (using pragmas or things like __attribute__), and a possibility
> to acquire position and size of that section (using linker magic).
>
> In general, you cannot assume a function generates just a single blob of
> assembly code in the ".text" sections. For example, functions containing
> string or floating-point literals, or large switches, often generate
> some data in ".rodata", static variables end up in ".data" or ".bss",
> and if you're doing C++, you'll get some exception handling tables as well.
>
>

That's a real good point. If the OP's goal was just to move the
function code--and not necessarily execute it after movement, he
may not care whether the bytes in the .rodata, .data, or .bss
segments get moved.

If the function has to be moved and executed, then it better
to be able to access the data in the .rodata, .data and .bss
segements---or not use data in any of those segments that are
in flash memory.

If you're moving the function to RAM because you can't execute
from Flash while updating flash, the function being moved
could be written to use only variables and data in RAM. This
might be the case if the function being moved is the Flash
write routine.

Now that I think about it, I may use this approach in writing
a firmware update routine for the MSP430---which has the
restrictions mentioned above.


Mark Borgerson

 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      01-23-2010
Mark Borgerson <(E-Mail Removed)> writes:

> At the expense of a few words of code and a parameter, you could do
>
>
> int MoveMe(...., bool findend){
> if(!findend){
>
> // do all the stuff the function is supposed to do
>
> } else Markend();
>
> }
>
>
> Where Markend is a function that pulls the return
> address off the stack and stashes it somewhere
> convenient. Markend may have to have some
> assembly code. External code can then
> subtract the function address from the address
> stashed by Markend(), add a safety margin, and
> know how many bytes to move to RAM.


You seem to be assuming that the compiler emits machine code that
is in the same order as the corresponding C code, i.e. that the
call to Markend() will occur at the end of MoveMe(). This is not
a good assumption.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
 
Reply With Quote
 
Mark Borgerson
Guest
Posts: n/a
 
      01-23-2010
In article <(E-Mail Removed)-september.org>,
(E-Mail Removed) says...
> In article <hjeah3$10g$(E-Mail Removed)>, (E-Mail Removed) says...
> > Mark Borgerson a écrit :
> > > In article <(E-Mail Removed)>,
> > > (E-Mail Removed) says...
> > >> On Fri, 22 Jan 2010 22:53:18 +0000, john wrote:
> > >>
> > >>> I need to know the size of a function or module because I need to
> > >>> temporarily relocate the function or module from flash into sram to
> > >>> do firmware updates.
> > >> Do you need to be able to run it from RAM? If so, simply memcpy()ing it
> > >> may not work. And you would also need to copy anything which the function
> > >> calls (just because there aren't any explicit function calls in the source
> > >> code, that doesn't mean that there aren't any in the resulting object code).
> > >>
> > >>
> > > At the expense of a few words of code and a parameter, you could do
> > >
> > >
> > > int MoveMe(...., bool findend){
> > > if(!findend){
> > >
> > > // do all the stuff the function is supposed to do
> > >
> > > } else Markend();
> > >
> > > }
> > >
> > >
> > > Where Markend is a function that pulls the return
> > > address off the stack and stashes it somewhere
> > > convenient. Markend may have to have some
> > > assembly code. External code can then
> > > subtract the function address from the address
> > > stashed by Markend(), add a safety margin, and
> > > know how many bytes to move to RAM.
> > >
> > >
> > > Mark Borgerson
> > >

> >
> > Sorry Mark but this is totally WRONG!
> >
> > The return address contains the address where the CPU RETURNS TO
> > when the current function is finished, not the end of the
> > current function!!!
> >
> > The return address will be in the middle of another function, that CALLED
> > this one.

>
> I think you missed a few points:
>
> Inside Markend, The return address on the stack will be the address
> after the call to Markend----which was purposely located at the end of
> MoveMe. Then next few instructions after the call to
> Markend will be the return from MoveMe (an RTS or equivalent with stack
> cleanup).
>
>
> Inside Markend, the return address on the stack will be
> an address near the end of MoveMe. It is that address that
> you need to save and make available for the computation
> of the function length.
>
> In assembly, the code in Moveme might look like this:
>
> 0900 MoveMe: sub.l #8, SP // make room for 8 bytes of locals
> 0904 test.l R14 // check the findend parameter in R14
> 0908 bne lbl1; // if true, just find end of function
> ....
> .... // all the work of Moveme goes here
> .... // and gets executed when findend is zero
> ....
> 1000 bra lbl2 // skip the markend call
> 1004 lbl1: bsr Markend
> 1008 lbl2: add.l #8, SP // clean up 8 bytes of local variables
> 1012 rts // return from MoveMe
>
> When Markend is called at 1004, the address 1008 gets pushed on the
> stack.
>
> Inside Markend, you could do:
>
> 2040 Markend: Move SP, NearEnd // NearEnd is a global variable
> 2044 RTS


Yikes! I'll have to mark myself down 5 points!!!

That should be
2040 Markend: Move @SP, NearEnd // NearEnd is a global variable

I need to save the data pointed to by the stack pointer, not the
contents of the stack pointer itself.


>
> Someplace else, could do
>
> MMLength = NearEnd - (unsigned long)&Moveme + 4;
>
>
> When I was teaching introductory M68K assembly language, I used
> to give exam problems with nested subroutine calls like this---some
> with pushed local variables, and ask the students to show
> the contents of the stack at some point in the function.
> Those questions really separated the As from the Bs and
> Cs!
>
> NOTE: You have to make sure that your compiler doesn't convert
> the Markend function to an inline sequence of instructions.
>
>


I also realized that, on the MSP430, I don't even need the
function call. At the end of the function whose
length I want to determine, I simply add the assembly
language:

mov PC, NearEnd


Both these methods do require some assembly language and
are processor dependent. The compiler that I'm using on
the MSP430 (Imagecraft), allows inline assembly, so
the instruction above would be

asm("mov PC, %NearEnd\n"); // the % is used to reference a C
//variable


I'm reasonably confident that I can use this technique to move
a flash-write routine, but I will have to be very careful
about using global variables, since the compiler produces
PC relative references to global and static variables. Those
references will be hosed when the code is moved.

Mark Borgerson
 
Reply With Quote
 
Mark Borgerson
Guest
Posts: n/a
 
      01-23-2010
In article <(E-Mail Removed)>, (E-Mail Removed)
says...
> Mark Borgerson <(E-Mail Removed)> writes:
>
> > At the expense of a few words of code and a parameter, you could do
> >
> >
> > int MoveMe(...., bool findend){
> > if(!findend){
> >
> > // do all the stuff the function is supposed to do
> >
> > } else Markend();
> >
> > }
> >
> >
> > Where Markend is a function that pulls the return
> > address off the stack and stashes it somewhere
> > convenient. Markend may have to have some
> > assembly code. External code can then
> > subtract the function address from the address
> > stashed by Markend(), add a safety margin, and
> > know how many bytes to move to RAM.

>
> You seem to be assuming that the compiler emits machine code that
> is in the same order as the corresponding C code, i.e. that the
> call to Markend() will occur at the end of MoveMe(). This is not
> a good assumption.
>

I'll paraphrase the old Reagan maxim: "assume, but verify". I
did a test run with an MSP-430 compiler and the call was at
the end. For that particular processor, as I later discovered
and noted in another post, you don't even need the
function call. You can save the contents of the PC at the
end of the function with a line of assembly.


This would certainly be a dangerous technique on a processor
with multi-threading and possible out-of-order execution.
I think it will work OK on the MSP430 that is the CPU where
I am working on a flash-burning routine.


Mark Borgerson
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Preferred Size, Minimum Size, Size Jason Cavett Java 5 05-25-2008 08:32 AM
Getting picture size/setting window size jodleren Javascript 2 02-15-2007 12:35 PM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM
Passing a C++ object's member function to a C function expecing a function pointer! James Vanns C++ 7 01-21-2004 02:39 AM



Advertisments