variable name, function arguments at run time in C

问题:

Is it possible to know a function arguments and variables' name types at runtime in C program ? For example, if I have a function:

int abc(int x, float y , somestruct z ){
    char a;
    int b ;
}

Can I know inside this function abc(), what are the names of arguments and variables i.e. in this case its x, y, z, a, b and they are of type int, float, somestruct, char, int.

Say if there is another function:

float some_func(specialstruct my_struct, int index){

} 

I should know that arguments name are my_struct, index and types are specialstruct, int.

I need this info at runtime ?

I have access to base pointer and return address , can I get required info using above pointer.

I was able to extract function name using return address and dladdr() function.

I see GDB does this, so it should be possible to extract this info?

回答1:

There is no kind of reflection or similar things in C. If you want such facility - you should design some utilities, macros for this purpose and use special coding rules to achieve desired effect. But IMO - it won't be a readable and understandable C code.

回答2:

There isn't really a native way to do this in C. In other languages, what you'd be looking for would be reflection. You can cheese it with macros and some tricks, but on a basic principle, you need to know variable names and arguments at compile time.

回答3:

There is a limited way of introspection provided by shared library functions dlsym and dladdr providing a name-to-address and vice versa translation. That is, however, not part of the C language, but rather a function supplied by the OS dynamic loader. You can, however, not deduct, for example, whether that symbol you found is a variable or function.

backtrace et al make up a GNU extension to the standard that allows to analyze the call stack of a function (call history). If there are symbols (function names) still present in the binary, backtrace_symbols will allow you to retrieve them.

The __LINE__ and __FILE__ predefined macros provide a way to dump where you are as well and can be the basis of some very useful macros for tracing.

And that's it. C does not provide any more introspection than that. Parameter names and types are gone in the binary, function signatures are gone and function result types as well.

回答4:

As others noted, reflection is not built into the C or C++ language. There are a variety of ideas here

However, Reflection is possible in C/C++ with a 3rd party library and debugging symbols in the executable or an external file.

The dwarfdump executable more or less does what you are hoping for. With the DWARF information details on function, variables, types, etc are available. In a similar fashion, the libdwarfdump functionality could be used by a process to inspect itself.

Here is a simple manual example:

typedef struct somestruct 
{
   int i;
   int j;
} somestruct ;

int abc(int x, float y , struct somestruct z ){
    char a;
    int b ;
}


int main(int argc, char* argv[])
{

   struct somestruct z;
   abc(1,1.0f,z);
   return 0;
}

and the partial output from dwarfdump

< 1><0x00000055>    DW_TAG_subprogram
                      DW_AT_external              yes(1)
                      DW_AT_name                  "abc"
                      DW_AT_decl_file             0x00000001 /tmp/dwarf.c
                      DW_AT_decl_line             0x00000009
                      DW_AT_prototyped            yes(1)
                      DW_AT_type                  <0x0000004e>
                      DW_AT_low_pc                0x004004ed
                      DW_AT_high_pc               <offset-from-lowpc>18
                      DW_AT_frame_base            len 0x0001: 9c: DW_OP_call_frame_cfa
                      DW_AT_GNU_all_call_sites    yes(1)
                      DW_AT_sibling               <0x000000ad>
< 2><0x00000076>      DW_TAG_formal_parameter
                        DW_AT_name                  "x"
                        DW_AT_decl_file             0x00000001 /tmp/dwarf.c
                        DW_AT_decl_line             0x00000009
                        DW_AT_type                  <0x0000004e>
                        DW_AT_location              len 0x0002: 916c: DW_OP_fbreg -20
< 2><0x00000082>      DW_TAG_formal_parameter
                        DW_AT_name                  "y"
                        DW_AT_decl_file             0x00000001 /tmp/dwarf.c
                        DW_AT_decl_line             0x00000009
                        DW_AT_type                  <0x000000ad>
                        DW_AT_location              len 0x0002: 9168: DW_OP_fbreg -24
< 2><0x0000008e>      DW_TAG_formal_parameter
                        DW_AT_name                  "z"
                        DW_AT_decl_file             0x00000001 /tmp/dwarf.c
                        DW_AT_decl_line             0x00000009
                        DW_AT_type                  <0x0000002d>
                        DW_AT_location              len 0x0002: 9160:        DW_OP_fbreg -32

With careful study, we can see the fragment defines the function 'abc' with arguements x, y and z.

The type of parameter x is an indirection to a type table with key 0x4e.

Looking elsewhere in the output, we can see the definition for type 0x4e. Type 0x2d is the somestruct which ties back to parameter z.

< 1><0x0000002d>    DW_TAG_structure_type
                      DW_AT_name                  "somestruct"
                      DW_AT_byte_size             0x00000008
                      DW_AT_decl_file             0x00000001 /tmp/dwarf.c
                      DW_AT_decl_line             0x00000003
                      DW_AT_sibling               <0x0000004e>

< 1><0x0000004e>    DW_TAG_base_type
                      DW_AT_byte_size             0x00000004
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_name                  "int"

The combination of ptrace, ELF, DWARF and the /proc filesystem allow gdb to read static and dynamic information for a process. Another process could use similar functionality to create Reflection functionality.

I have used variants of this strategy to create custom debuggers and memory leak detectors. I have never seen this strategy used for business logic however.