Getting the code size of a function in C

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I need to determine the size of a function or module since I need to
temporary relocate the function or module from flash into sram for
firmware updates.

How can I find that out during runtime. The
sizeof( myfunction)
generates an error saying "size of function unknown".

Thanks.

Re: Getting the code size of a function in C

Quoted text here. Click to load it

You'll need to do something in your linker script to create
global symbols before and after the function.  In your C code,
you should then be able to take the address of those global
symboals and do some math to determine the size.

--
Grant Edwards                   grante             Yow!  UH-OH!! We're out
                                  at               of AUTOMOBILE PARTS and
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it

If you're using GCC, probably you do not need to
copy anything, just locate your function to the initialized
data section:

/*   Write unlock sequence    */

static void unlock(void) __attribute__((section(".data")));
static void unlock(void)
    {
    FLASHMEM[KEYLOC1] = KEY1;
    FLASHMEM[KEYLOC2] = KEY2;
    }

This is the Flash unlock routine from an embedded
system.

--

Tauno Voipio
tauno voipio (at) iki fi


Re: Getting the code size of a function in C

Quoted text here. Click to load it

That works, but it can be a bit of a waste since the function
is sitting in both flash and RAM 100% of the time.  If there
are multiple routines that need to be run from RAM at different
points in time, you can save a bit of RAM by overlaying them.

--
Grant Edwards                   grante             Yow!  I'll show you MY
                                  at               telex number if you show
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it

The amount of code needed in RAM for Flash writing is pretty
small: about 250 bytes on an ARM for garden-variety AMD Flashes.

--

Tauno Voipio
tauno voipio (at) iki fi

Re: Getting the code size of a function in C

Quoted text here. Click to load it




But where is the "flash writing" code getting the data?  

In cases I've dealt with the "flash writing" code has to
impliment some sort of communications protocol in order to
receive the data to be programmed into flash.  In the product
I'm working with right now, it takes 3KB of code to do a flash
update.  That's a pretty significant chunk out of my 32KB of
RAM.

--
Grant Edwards                   grante             Yow!  Xerox your lunch
                                  at               and file it under "sex
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it


You do not need to keep the whole chunk in RAM at the same time.
Also, only the inner loop of a Flash writer is necessary to be
kept in RAM, the rest can reside in the Flash. The code responsible
for the handling from the unlock sequence till the chip responds
ready to poll has to be in RAM, but this is for erasing a segment
or writing a single byte. The rest of code can be safely in the
Flash without any problems.

The incoming data is usually transferred in some kind of chunks
(e.g. 128 bytes with Xmodem). It's no too difficult to keep
one chunk in the RAM and read more when that's written.

--

Tauno Voipio
tauno voipio (at) iki fi

Re: Getting the code size of a function in C

Quoted text here. Click to load it

You're right. I could split up the loader and keep part of it
in flash, but it's extra work and it doesn't buy me anything.
Once the decision is made to update flash, the entire RAM space
becomes available.  The data that's there belongs to an
application that's being erased.  It's a lot simpler to just
copy the entire loader into RAM and run it from there.  Up
until that point, the loader is using 0 bytes of RAM.

Quoted text here. Click to load it

It could, but there's no advantage to doing so.

Quoted text here. Click to load it

Right.

--
Grant Edwards                   grante             Yow!  The Osmonds! You are
                                  at               all Osmonds!! Throwing up
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C

Quoted text here. Click to load it

... so just assume the function occupies all the RAM, and copy that many bytes.

Re: Getting the code size of a function in C

Quoted text here. Click to load it

Sure, but once you've put in a label so you know where the
function starts, putting in a second one so you know where it
ends only takes a couple more keystrokes.

--
Grant Edwards                   grante             Yow!  An air of FRENCH
                                  at               FRIES permeates my
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C

Quoted text here. Click to load it

Except that unlike the single starting point, which usually must exist
for the C function to be callable from unrelated translation units,
there's no particular reason for a given C function to even *have*
exactly one end where such a label could be put.  Nor is there a
requirement that the entry point be at the start of the code region
for that function.

There's not even a requirement that a C compiler would have to
translate a single function to a single, consequtive block of code.
Optimization by function tail merging exists.

As I stated elsewhere in this thread: it's easily possible that on a
given platform the only way of pulling this off is by coding all the
relevant parts in assembler.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Getting the code size of a function in C
Quoted text here. Click to load it

Nonsense.  There is some address X such that all bytes in the
function have addresses less than X.  Unless you've got some
weird non-linear memory addressing scheme.

Quoted text here. Click to load it

That's why adding global labels before and after the function
is much safer than useing the function pointer for anything.

Quoted text here. Click to load it

It may not be a requirement, but I've never seen a C compiler
that didn't.  This is comp.arch.EMBEDDED.  We've got to work
with real-world toolchains here, not some imaginary "could do
anything the ISO spec allows" toolchain.  comp.lang.c is that
way --->

Quoted text here. Click to load it

I've been doing embedded C for 20 years on a dozen different
target architectures and at least as many toolchains.  I've
never seen a target/toolchain where what the OP wants isn't
easily doable with some trivial linker-script hacking.

--
Grant Edwards                   grante             Yow!  WHOA!! Ken and
                                  at               Barbie are having TOO
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it

OK. Have a look at the Hi-Cross C Compiler. It translates
every function into a separately linked unit. The units
are linked in only if there are references to them. The
addresses allocated by the linker for consecutive functions
are not consecutive. For the reasons in this discussion
(Flash writer) I tried to find the function sizes, but
failed miserably.

The binary file created was also a jumble of criss-
crossed function-size pieces, so that I had to make
an extra pre-sorting and merge pass before writing
to Flash.

My guess is that the functions were ordered by the
stored call tree order collapsed in a weird way.

--

Tauno Voipio
tauno voipio (at) iki fi


Re: Getting the code size of a function in C

Quoted text here. Click to load it

Yup, that's exactly the same as the way gcc/ld works (at least
that's how I use it for embedded work).

Quoted text here. Click to load it

In the linker script isn't there any way to tell it to link in
a "unit" and put that "unit" into a specified section of
memory?

Quoted text here. Click to load it

But the link should still put them into the specified output
sections, shouldn't it?

--
Grant Edwards                   grante             Yow!  With YOU, I can be
                                  at               MYSELF... We don't NEED
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it

Nope. The linkable unit in GCC is a module, not a single
function. Hi-Cross separates even functions within a module.

Quoted text here. Click to load it

Hi-Cross does not have such a thing. There is a primitive
sectionization, but nothing else.

Quoted text here. Click to load it

See above.

After sorting, the final output was a sensible binary
file in one piece, but the functions that were together
in the source in a module, were usually no longer together
in the final file, except occasionally. It is pretty clear
that there is then no way to put in labels to calculate
the size of a function. The code (M86k) is inherently
position-independent in small functions, so the only
problem was to get the size of the code.

--

Tauno Voipio
tauno voipio (at) iki fi

Re: Getting the code size of a function in C

Quoted text here. Click to load it

So does the Gnu toolchain if you tell it to.  If you use the
-ffunction-sections option, each function goes into it's own
section. This means that each function is a linkable unit. [For
most purposes, it's the same as putting every function in a
separate file.]

When you link, you specify --gc-sections, and only sections
(functions) that are referenced will be linked into the output
image.

This also means that in the linker script you can specify a
separate output section for a particular function if you want
to.  Once the function is in its own section, finding the size
of that section is trivial using the SIZEOF() operator in the
linker script.

In all the other toolchains I've used (which I guess weren't
all that representative) you could easily accomplish much the
same thing if the function was placed in its own file.

[You can also do the same thing with variables: if you use
--data-sections when compiling then unreferenced global
variables will not be linked into the output image.]

Quoted text here. Click to load it

Hi-Cross sounds like a nasty bit of work.

--
Grant Edwards                   grante             Yow!  I had pancake makeup
                                  at               for brunch!
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
Quoted text here. Click to load it

We were not asking for it, but how to avoid it.

If we're talking about GCC and the GNU toolchain, the
whole discussion is moot: there are plenty of ways
to create the desired effect. IMHO, the by far easiest
is to sectionize and locate the function to .data,
so we do not need to consider position-dependency
issues at all and the start-up code does the loading
of the function code to RAM.

Quoted text here. Click to load it

It is a family of compilers sold for embedded work.
The OP question was about C language without specifying
a compiler.

AFAIK, Hi-Cross is not alone with this kind of
'innovations' in the mebedded world.

--

Tauno Voipio
tauno voipio (at) iki fi

We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C

Quoted text here. Click to load it



Indeed, such an address X must exist --- but calling 'the end' of that
function may be premature.  There's no general way of making sure that
between X and that other label, you'll have enclosed significantly
less than the entire program, and even less that positioning such
labels in the C source has any relation with the actual address range
covered by (fragments of) the function.

And that's only scratching the surface.  Next you'll have to worry
about other functions being called by the function in question, often
without the C source showing any sign of their existence.  E.g. on
some C-unfriendly architecture, accessing a structure element in an
array of structures in "far" memory can easily cost 3 or more calls to
"secret" C runtime library functions.

Quoted text here. Click to load it


Then, with all due respect, you haven't been looking closely enough.

Quoted text here. Click to load it

Let's stay right here, shall we?  I hope we can agree that Keil C51
(current version) is quite definitely a realq-world toolchain, and as
embedded as they come, right?  So: inspect what its optimization
options like "reuse common entry code", "common block subroutines",
and particularly the machinery they call "linker code packing" can do.

Fact is that a single function can fall apart into multiple distinct
blocks of code, which the linker can principally distribute all over
the place, if it so wishes, and that toolchains doing this not
actually exist, but are highly relevant in this newsgroup.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Getting the code size of a function in C

Quoted text here. Click to load it

I never said anything about position labels in C source.  I
thought I was quite explicit that I was talking about using the
linker script for placing symbols before/after the memory
section containing the function.

Quoted text here. Click to load it

Of course.


Then relocating that function probably won't work if the called
functions aren't available.  It's quite easy to determine if
that's the case by looking at the generated assembly.

Quoted text here. Click to load it

Then don't use those optimizations.

Quoted text here. Click to load it

With all the toolchains I've used, there was always a way to
place a function into a distinct section of memory such that
that section's start/end addresses could be made globally
visible at link-time.  It may have required placing the
function in a separate file and not using optimizations, but it
was never that hard.  If the Keil 51 compiler really is that
difficult to work with, then I'm glad I never had to use it.

--
Grant Edwards                   grante             Yow!  Excuse me, but didn't
                                  at               I tell you there's NO HOPE
We've slightly trimmed the long signature. Click to see the full one.
Re: Getting the code size of a function in C
"Grant Edwards" ...
Quoted text here. Click to load it

Sure:                        Avocet C51 V3
Not sure anymore (long ago): IAR C51

AFAIK a 8051 is embedded stuff   ;-)

Arie de Muynck



Site Timeline