2

I am new to linux. I want to know the starting address and its size of different segments (like stack, heap, data etc.) and its current usage.

I like to know how to find both in running process and in core dump.

Thanks in advance.

Thangaraj
  • 3,038
  • 7
  • 40
  • 43
  • 2
    possible duplicate of [GDB: Listing all mapped memory regions for a crashed process](http://stackoverflow.com/questions/5691193/gdb-listing-all-mapped-memory-regions-for-a-crashed-process) – Ciro Santilli OurBigBook.com Jun 04 '15 at 10:21

4 Answers4

7

start by looking into the proc(5) filesystem. man is your friend.

/proc/[number]/maps A file containing the currently mapped memory regions and their access permissions

in gdb, you can use

$ gdb -q
(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
  mappings -- list of mapped memory regions.
  stat     -- list a bunch of random process info.
  status   -- list a different bunch of random process info.
  all      -- list all available /proc info.

have a look at info proc mappings, except it doesn't work when there is no /proc (such as during pos-mortem debugging).

Fredrik Pihl
  • 44,604
  • 7
  • 83
  • 130
  • what about dump? In case of running process, which file I need to look to get appropriate data? – Thangaraj Jul 08 '11 at 09:44
  • @Fredrik - Trying to understand this. For this to work, shouldn't that executable which the user wants to see maps of sections for be running as some daemon or something. If it just executes and ends quickly, then to use /proc/ based info in that case, how would it work? – goldenmean Jul 08 '11 at 13:56
2

There is the pmap command. It displays the information available in /proc/PID/maps in different ways. Plus, it adds header and summary lines. This may be more readable to you than the /proc/PID/maps pseudo file.

Sadly, it does not have the ability to analyze core dumps.

hagello
  • 2,843
  • 2
  • 27
  • 37
2

objdump on Linux gives information about a binary. Check man objdump. It gives - sections, disassembly, debugging symbols.

objdump -h <binary> 

objdump --section=name 

Better way, if possible(if you can build the executable yourself from source) generate a map file while compiling and linking the source code, by giving appropriate compiler/linker option. The map file will sure have all the information about sizes, starting addresses of different sections.

goldenmean
  • 18,376
  • 54
  • 154
  • 211
  • I believe the heap and stack segment would be present in program header. But in case of object files, program header may or may not be present right. Correct me if am wrong. – Thangaraj Jul 08 '11 at 11:29
  • @Thangaraj - Of course it would contain the program header. I assume you are talking about a ELF executable file format.(Even if COFF format, the COFF header shall have the sections) So apart from objdump, use readelf, elfdump to 'see more into' the executable. Why the downvote BTW? – goldenmean Jul 08 '11 at 12:38
  • at runtime, I believe at runtime the address might change from static data. Down vote is not mine. – Thangaraj Jul 11 '11 at 05:18
  • @Thangaraj - objdump -h gives both Physical and virtual addresses of various sections. Try it. – goldenmean Jul 11 '11 at 11:33
0

Use `maintenance info sections' within gdb to print all the segments that are mapped into the process address space.