0

My question is related to In the ARM ABI, how are global variables accessed? but is somewhat different.

I'm trying to debug an issue and for that I went looking in the build outputs of my project. I consider an ARM cortex-M processor.

I have a global variable and I wanted to see in the disassembly code where is accessed. I looked at the map file and saw it indeed appears as a symbol. However, as suggested in the referenced question, I cannot see its label or it address in my disassembly.

I presume this means it is always accessed via some other address + a shift.

Presumably there are many load access occurrences. Is there any effective way to locate access to this global variable in the disassembly?

Edit per Comments:

  • I have the source code. I'm looking at the disassembly for debugging something.
  • I'm not using gcc but clang
  • the code is bare metal Code that uses interrupts and no dynamic memory allocations.

My motivation is two fold:

  1. First I wish to expand my horizons and learn.
  2. I wonder regarding access times. When looking at the disassembly, it seems access to global a is more involved and requires more instructions than local variables.
Improve this question
4
  • These will be in the 'literal table'. Normally, I don't think the literal tables are disassembled. If you use objdump, it has '--disassemble-all'. The literal table may be 'rodata' or some other section based on the system. You can locate instances with ldr RX, [PC, #YY] as you can see in the accepted answer to your reference question. At the value [PC, #YY] is the address of the global. System to system, a global maybe relative or absolute. The '[PC,#YY]' places the absolute address in a relative code section; this is typical, but you could be REing a system with relative access. Commented Apr 23 at 16:26
  • 1
    Your question is much better imho now. Regarding 'regarding access times'... One issue is the completeness of knowledge. A local variable can not be modified outside the compile module. As such the compiler can make assumptions that only it has changed the value (not some other version of it (ie compiling some other module)). I think you might find it instructive to label a 'global' with/without static and compile at different optimization levels. Indeed the assembler is the end result, but not understanding compiler theory can make this question difficult to answer directly. Commented Apr 25 at 16:36
  • 1
    Here my guess that you additionally wonder why the compiler may load/reload a global variable. See: Linux memory barriers; if you understand all that, you will understand this issue. Maybe just look at section 'EXPLICIT KERNEL BARRIERS' and 'compiler' specifically. Shortly these are Linux techniques to prevent what you see. With a local, the compiler is sure of itself and these techniques are not needed [well actually barriers may tie more to volatile]... Commented Apr 25 at 16:40
  • 1
    Here is a trite google search. Global variable consider harmful. Also try 'what every programmer should know about xxx', 'xxx considered harmful' for some other copy-cats of seminal computer science papers. Leads to this closed SO question... In fact, it is kind of a concept behind C++ (augmenting static and struct with class). Commented Apr 25 at 16:51
Load 6 more related questions Show fewer related questions

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.