public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/12285] New: Add sizeof_function functionality
@ 2003-09-15  8:52 mkgnu at gmx dot net
  2003-09-18  7:34 ` [Bug middle-end/12285] " pinskia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: mkgnu at gmx dot net @ 2003-09-15  8:52 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285

           Summary: Add sizeof_function functionality
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mkgnu at gmx dot net
                CC: gcc-bugs at gcc dot gnu dot org

I am requesting the feature of adding a means of computing the size of a
function at run time. 

This is currently accomplished using something similar to...

#define END_OF_FUNCTION(name) void name##_end(void) { }
#define END_OF_STATIC_FUNCTION(name) static void name##_end(void) { }

void func1(void) { ... } END_OF_FUNCTION(func1);
void func2(void) { ... } END_OF_FUNCTION(func2);

...and then manually computing &function_end - &function_name + 1

However this approach cannot be used for computing the size of ANY function
unless all functions are defined that way, which makes it "difficult" to deal
with large scale projects (e.g. linux kernel).

Discussions regarding this feature can be found at:

http://gcc.gnu.org/ml/gcc-help/2003-07/msg00067.html

Please contact me for more information.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
@ 2003-09-18  7:34 ` pinskia at gcc dot gnu dot org
  2003-09-18 16:03 ` mkgnu at gmx dot net
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-09-18  7:34 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-09-18 07:23 -------
What would the use of the sizeof function anyway?
The only use I can think is that you want to copy it but the sizeof of function should all be 
handled by the dynamic linker (or static linker if the case you are linking staticly).  Also 
note what about functions which have multiply entry points how do you handle those?
I think this feature should not also be in GCC but you should be in the dynamic linker.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
  2003-09-18  7:34 ` [Bug middle-end/12285] " pinskia at gcc dot gnu dot org
@ 2003-09-18 16:03 ` mkgnu at gmx dot net
  2003-09-19  6:27 ` wilson at specifixinc dot com
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: mkgnu at gmx dot net @ 2003-09-18 16:03 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285



------- Additional Comments From mkgnu at gmx dot net  2003-09-18 15:50 -------
The use of sizeof_function() would be to calculate during compile the size of a
function's text segment. One may want to copy that function during runtime and
create multiple copies of it (e.g. create new functions based on a template).

I am not sure what needs to happen on the case that a function has multiple
entry points. Any C function you compile will result into a text segment. I
don't see where the multiple entrypoints are. It may be called from different
other functions, but that doesn't matter. I don't think I understand what you mean.

Please read the thread.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
  2003-09-18  7:34 ` [Bug middle-end/12285] " pinskia at gcc dot gnu dot org
  2003-09-18 16:03 ` mkgnu at gmx dot net
@ 2003-09-19  6:27 ` wilson at specifixinc dot com
  2003-09-19  9:52 ` mkgnu at gmx dot net
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: wilson at specifixinc dot com @ 2003-09-19  6:27 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285



------- Additional Comments From wilson at specifixinc dot com  2003-09-19 05:17 -------
Subject: Re:  New: Add sizeof_function functionality

mkgnu at gmx dot net wrote:
> I am requesting the feature of adding a means of computing the size of a
> function at run time. 

If your target is ELF, then there is already function size info in the 
ELF symbol table.  Try objdump -t executable.  The first number is an 
address, the second number is the size of the symbol.

The compiler doesn't have enough info to compute function sizes.  It has 
to defer it to the assembler by putting a laberl after the function end 
and then subtracting labels.  This is what we do to get the ELF symbol 
table size info.  The only way to get this info back into C code would 
be to store it in a variable somewhere, but since the value is already 
in the symbol table, it would be wasteful to have a second copy of it.

If you are trying to copy functions around, you probably need to be 
looking at ELF headers anyways, so getting the info from there shouldn't 
be too much trouble.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
                   ` (2 preceding siblings ...)
  2003-09-19  6:27 ` wilson at specifixinc dot com
@ 2003-09-19  9:52 ` mkgnu at gmx dot net
  2004-01-01  1:04 ` pinskia at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: mkgnu at gmx dot net @ 2003-09-19  9:52 UTC (permalink / raw)
  To: gcc-bugs

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285



------- Additional Comments From mkgnu at gmx dot net  2003-09-19 06:55 -------
> If your target is ELF, then there is already function size info in the 
> ELF symbol table.  Try objdump -t executable.  The first number is an 
> address, the second number is the size of the symbol.

I am trying to get the size of a function compiled for the linux kernel, inside
the kernel. I need the function size info present during runtime.

> The compiler doesn't have enough info to compute function sizes.  It has 
>to defer it to the assembler by putting a laberl after the function end 
>and then subtracting labels.  This is what we do to get the ELF symbol 

Which is precisely what I'm faking using macros.

> table size info.  The only way to get this info back into C code would 
> be to store it in a variable somewhere, but since the value is already 
> in the symbol table, it would be wasteful to have a second copy of it.

You said "since the value is already in the symbol table". What do you mean ? Is
the symbol table available during runtime ? The value is not present in a binary
image (contained in a 4 byte variable). The value may be computed using
information contained in an ELF image. Right ?

What I need then is a C extension that will have the same effect as adding a
label at the end of the function (which I manually have to do with macros) and
computing that size during assembly time. The space allocated for that in memory
would be an unsigned long (4 bytes). During assembly time when the exact size is
computed, it can be filled in.


> If you are trying to copy functions around, you probably need to be 
> looking at ELF headers anyways, so getting the info from there shouldn't 
> be too much trouble.

I am looking to generate and modify code during runtime, and I need a way to
know where a function starts and ends. There's a starting label. But no ending
label. I faked my way around that using macros for just a few functions, but I
need a systematic way of always having that information available during runtime
for all functions.

Are you suggesting that I put together a script that objdumps every .o file in
order to get function sizes, and that generates a .asm with global variables for
all possible function names that I should have declared as externs in the
original .[cS] files ? That sounds inefficient since I then have a huge
collection of variables I may not use, but nevertheless interesting. Hmm...maybe
declare those as static so they only get linked in the final kernel image if used ?

Would this be a way of adding symbol table information in a binary file that are
accessible during runtime ?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
                   ` (3 preceding siblings ...)
  2003-09-19  9:52 ` mkgnu at gmx dot net
@ 2004-01-01  1:04 ` pinskia at gcc dot gnu dot org
  2004-01-01 19:16 ` mkgnu at gmx dot net
  2004-04-27 19:05 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-01-01  1:04 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-01 01:04 -------
Again this is only usefull when you are going to use asm which you should use asm in 
the first place.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
                   ` (4 preceding siblings ...)
  2004-01-01  1:04 ` pinskia at gcc dot gnu dot org
@ 2004-01-01 19:16 ` mkgnu at gmx dot net
  2004-04-27 19:05 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: mkgnu at gmx dot net @ 2004-01-01 19:16 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From mkgnu at gmx dot net  2004-01-01 19:16 -------
Reopened bug.

Again, I will have to disagree and ask that this bug is assigned the minimum
priority and remain open.

By your same argument, there is no need for the "&" C operator. You should be
using asm to get the memory address of the beginning of a function, or variable
location. Having this feature will allow C programs to self-discover the size of
 their functions. They can become introspective.

It _IS_ possible to use a function attribute that will generate an end_label at
the end of each function so that one can compute the size of a function during
compile-time. You can emit the following asm using this C program:

int func()
{
printf("The size of this function is 0x%lx\n", size_of_function(func));
}



func:
...
push func_end_label-func
call printf
...
func_end_label:

GCC itself can emit this, with no modifications needed to as or ld. The fact
that the workaround I use so far is a macro, proves that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug middle-end/12285] Add sizeof_function functionality
  2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
                   ` (5 preceding siblings ...)
  2004-01-01 19:16 ` mkgnu at gmx dot net
@ 2004-04-27 19:05 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-04-27 19:05 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-27 18:47 -------
This functionality cannot happen if function cloning happens for inline so this will and 
cannot be done.  Also it will not work on the mainline when compiled with the hot/code 
partitioning turned on as the size will be wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12285


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-04-27 18:47 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-15  8:52 [Bug c/12285] New: Add sizeof_function functionality mkgnu at gmx dot net
2003-09-18  7:34 ` [Bug middle-end/12285] " pinskia at gcc dot gnu dot org
2003-09-18 16:03 ` mkgnu at gmx dot net
2003-09-19  6:27 ` wilson at specifixinc dot com
2003-09-19  9:52 ` mkgnu at gmx dot net
2004-01-01  1:04 ` pinskia at gcc dot gnu dot org
2004-01-01 19:16 ` mkgnu at gmx dot net
2004-04-27 19:05 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).