Quote:
Originally Posted by
Praveen_218
I've got the following two queries:
1) What's the difference in performance if a variable storage is at bss and not at the data section (apart from the initialization to zero in case of data section variables --like static variables).
As far as the hardware's concerned, memory is memory. The bss segment isn't special.
Quote:
In general, why a developer need to bother about the storage location of a variable which is on the bss section?
Generally, they wouldn't care what segment it was in unless they were programming in raw assembly. C programmers don't deal with segments, just variable scope. Global or static variables would end up in bss.
Quote:
2) Does the ELF format has such memory sections / layout (Stack, bss, dataSection, rodata, heap) of any program? Is that hardware supported?
The ELF format tells the kernel what memory segments a program expects where, what can be relocated, any shared libraries that need mapping, etc, etc. It's quite complex. The ELF format itself isn't hardware-supported, since it's the kernel's job to manage memory, but virtual memory itself is supported in hardware on most any modern platform and OS.
Quote:
I'm looking ahead to have a good general discussion on process memory layout, please?
Process memory layout is all virtual these days. The kernel keeps a table of what memory addresses a process is allowed to use and what physical memory(if any) they are associated with. Each process' memory is independent
* The processor of course supports this table in hardware, otherwise all memory operations would be painfully slow!
The binary code in an ordinary executable, as well as things like its stack, are by tradition loaded/created in consistent locations. Shared libraries on the other hand are generally relocatable.
If you're interested in memory segments, you may find
A Whirlwind Tutorial on Creating Really Teensy ELF Executables enlightening, it goes right to the heart of segments and ELF itself.
* Oversimplification, but mostly true as far as the programmer's concerned
