ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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
Now, How can I know that Variable belongs to its function?
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?
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) p &comm_tk_init:rueba
$3 = (UINT *) 0x8068748 <prueba.3188>
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.
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.
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.
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...
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.
% gdb comm_tk
GNU gdb (GDB) 7.4.1-debian
Reading symbols from /home/npostavs/tmp/comm_tk...done.
(gdb) info functions
All defined functions:
(gdb) info scope comm_tk_cyclic
Scope for comm_tk_cyclic:
Symbol prueba is in static storage at address 0x6008f4, length 4.
(gdb) info scope comm_tk_init
Scope for comm_tk_init:
Symbol prueba is in static storage at address 0x6008f8, length 4.