static local vars doubt.....
 

Hello,

I have two functions and both has a static local var....

Now, I check address of each var..

Now, How can I know that Variable belongs to its function?
I suppose that gcc add that number but what is the criteria?

Best regards.

I do not think there is an "official" way for it, because those vars are local and access is not allowed from outside. So you need to find the function itself, disassemble and you will find the address of the given local variable

Strictly speaking, static “local” variables do not belong to anyone, but since they are defined inside a function, their scope is function's body, which means that they can be accessed (by name) only inside the function.

Short answer to your question is: you cannot. Why would you even need that? What is a problem you are trying to solve?

Hello,
Thank you for fast answers.

Well, I have developed a function that if I give it a name of var, it return me address, type and length of var using GDB/MI. With global variables, it works fine.
Now, I am interesting in use the same function with local vars, but with static local variables I cannot give the name because gdb return me error "No symbol "prueba" in current context" and it is normal.

But if you use other nomenclature...
GDB return me correct information.

I'm looking for a relationship between the function and the name of the variable, but understand that your response will be somewhat difficult.

no, it is not difficult at all. I think there is no logical relationship, so those numbers (pointers) are more or less random-like ones.

So, in few words....

prueba.3188 --> comm_tk_init::prueba
prueba.3192 --> comm_tk_cyclic::prueba

any advice.

Why do you need that? Probably the variables counted and that is the result or that is something like "distance" in bytes from somewhere....

First you should understand there are two different kinds of information that gcc puts in the object code for those symbols.

It puts in information needed by the linker to build the correct binary. That is the information you have looked at. In that kind of information, the size of each of those symbols is indicated, but the scope is not (the linker decides on the address). As others indicated, the info for the function indicates how to find the variable, but the info for the variable has no need to point back to the scope.

There is also optional debugging info, that is transformed by the linker into the information used by gdb. The kind of information you want is in that debugging info. I don't recall what commands you use to get readable information from the debugging info in an object file.

Exactly.

local is a scope, or if you will visibility modifier. The variable-name is visible only to the local context in which it is defined. A static variable that is local will also be a unique instance ... if two separate subroutines define a local variable named x, it will be a distinct variable whether-or-not it is static.

static causes a single unique memory address to be assigned to that variable, and for the lifetime of that address to be the lifetime of the program.

A function is free to divulge the address of one of its local static variables if it wishes to do so, thereby giving anyone else access to it by means of a pointer or indirect reference.

The runtime debugger acts on memory-address based information, and, in the particular situation that you are describing, it can indeed be confusing although it is correct.

Hi,

well, I understood all post.

local is a scope and if I declare a variable as static in two different functions with the same name, both variables are different and it has own address memory.

But my questions is:
Can I looking for debug information of this vars????
How can I detect that Variable belongs to its function????

prueba.3188 --> variable prueba in comm_tk_init function.
prueba.3192 --> variable prueba in comm_tk_cyclic function.

is it possible to obtain this information with any debug tool like gdb for example?
Note: I dont know the struct of program.

with "nm" tool.....
second step: how to know that Variable belongs to its function????

Best regards.

No, you still not understand. Scope works on the language level, I mean you will use it inside the c/c++ code to define accessibility. The compiler checks it and will throw and error in case of a violation (syntax rules). That is the first task what a compiler must do.
The following phases will translate to code to binary, will collect all the variables (probably some optimization will happen) and will construct a result file (lib, app, whatever). Here you do not need/have scope at all, and also using direct memory access you can reach whatever you want. In this level you have only pointers to different parts of the memory...

However, with debug symbols it should be able to get from the pointer back to the variable, and I'm guessing that's what OP is asking about.

I'm far from expert in this stuff, but I tried creating a .c file similar to what the OP described, then compiling (gcc -g -c ...) to create a .o file with debug info. Then I used readelf -w to dump out the debug info from the .o file.

It is very verbose, with lots of content (such as from the include files) that I don't really understand.

But searching for the repeated variable name, it was easy to find a (DW_TAG_variable) section in the output for each of them. Then searching backward in the output from that DW_TAG_variable section, I could find the next earlier (DW_TAG_subprogram) section, which appears to give the scope of the variable. So I can infer the basic rules.

I also put another static variable of the same name at module scope (outside of any subprogram) and was surprised to see its DW_TAG_variable at the end of the output with nothing that I understand telling me it is not part of the next earlier DW_TAG_subprogram.

So there is more complexity than I can deduce with a quick test. Maybe there is enough complexity that studying the source code of readelf would be required.

But close to what the OP wants can be achieved by parsing the output of readelf. It would be better (though I'm not sure whether harder or easier) to do the same by calling the same functions that readelf calls. That is part of the beauty of open source.

Edit: I wasn't looking at the obvious. Each section of that output starts with a level number in <>. So the variables in subprogram scope each start with <2> so you know to look backward for the next earlier <1> to get their scope. The static variable at module scope has its section start with <1> so you know there is no outer scope. The file is also identified. There is a DW_AT_external entry in the global sections to distinguish a <1> meaning global from a <1> meaning file scope.

Edit2: After figuring all that out, I looked again at the output the OP showed in the first post. When I first saw that, I knew neither where the OP got that output, nor what it meant. But I see it is nearly the same as what I got from readelf -w including the key fact (that may be the whole answer to the OP's question) that the level numbers <1> and <2> combined with the sequence in which those sections appears, tells you the way the scopes nest.

Hello johnsfine,

Thank you.
Yes, you are right. With dwarf, is clear ( more or less ) how to find variables.

I would like to make the same with GDB but it is more complex.

Best regards.

Maybe gdb's info scope command is what you need: