0

ELF output of readelf

In this case, is right that address of:

.data start at 0x08048054 up to 0x08048054+0x0000e

.bss start at 0x08048054+0x0000e up to 0x0804805+0x00016

or am I missing something? please clarify it for me.

EDIT

I used this command to get the information as in the image:

readelf -l filename
The Mask
  • 17,007
  • 37
  • 111
  • 185
  • Do you have access to the Linker Script or was this compiled with the default linker script? If so, what compiler/linker was used? – nonsensickle Apr 09 '14 at 03:12
  • The problem is, you have no way of knowing which comes first **bss** or **data** unless you get the linker script information (assuming that you're using GCC or Clang). – nonsensickle Apr 09 '14 at 03:14
  • @nonsensickle: It was compiled with an old C compiler. I don't know the linker was used but I can try figure out. But usually `.bss` comes first, it's the behavior on most compilers, in this case, if we assume it's for this compiler too, am I right about the address? – The Mask Apr 09 '14 at 03:35
  • If you're assuming that `.bss` comes first then `.bss` would be at `0x08048054` and `.data` would be at `0x08048054+0x0000e`. Yes, it is a fair assumption to make. – nonsensickle Apr 09 '14 at 03:37
  • the executable isn't dynamically linked as file command says: `ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped` in this case, there's no a linker script, isn't? – The Mask Apr 09 '14 at 03:39
  • 1
    Correct, the library itself would contain the symbol information which would then go through a linker script that your application uses. So, if that's the case, you can actually control the order in which the `.bss` and `.data` are layed out. – nonsensickle Apr 09 '14 at 03:40
  • @nonsensickle: Sorry, I wanted to mean **.data** comes first usually. – The Mask Apr 09 '14 at 03:40
  • @nonsensickle: Thanks very much for comments. You could consider porting to answer. Last question: if I have two global variables with uninitialized values, say, `a` and `b` on 32-bit machine where `sizeof(int) = 4`, `a` is at `0x08048054+0x0000e` and `b` at `0x08048054+0x0000e+0x4` right or should I consider something else? – The Mask Apr 09 '14 at 03:44
  • Uninitialized globals and globals initialized to zero live in the `.bss` segment. If that is where we have agreed `.bss` segment is, then we can assume that `a` and `b` are both in that block of memory. I have answered similar questions in the past and will try and get you some of the links I had in them. – nonsensickle Apr 09 '14 at 03:48
  • Thanks again. It's such a big help! I'm trying to understand ELF file format(to generate my own). I didn't find myself a tutorial which I could understand these specific stuff(I have already ELF file spec) so I'm studying output of some old compilers because there's less complexity and it's better for learning for now. – The Mask Apr 09 '14 at 03:56
  • Sorry I couldn't find the links I thought I had. Instead here's a blog post I made a while ago. Not all of it is relevant but I do mention where you can expect your variables to be placed when using C. http://blog.lazar.co.nz/post/71304177510/how-an-arm-cortex-m3-boots, you can safely skip about half of that post and go to the linker related stuff. – nonsensickle Apr 09 '14 at 04:12
  • Thanks for article. I've read all article. Well done. Another (last, really) question still related: when we create a second `PT_LOAD` segment that's our `.data + .bss` sectios "together", sizes p_filesiz and p_memsiz are requested and the kernel is up to allocate(is allocate the corret word?) `p_memsiz` bytes and zero the difference between `p_memsiz` and `p_filesiz`, – The Mask Apr 09 '14 at 16:52
  • [continuation...] ie., `N = p_memsiz - p_filesiz` and `N` is the `.bss` memory region now filled by zeroes. In this case, where is the address of this block newly allocated by the kernel? ie, the begging of this block memory region (in our case here, at `0x08048054`) does the kernel modify p_paddr and put the address in there? I hope it's clear. – The Mask Apr 09 '14 at 16:52
  • (sorry, I mean `p_vaddr` in the previously comment) – The Mask Apr 09 '14 at 20:21

2 Answers2

1

Ok, so where do I begin... Yes both .data and .bss are in that region in memory. The problem is that there is no way to figure out what order they are in.

We can assume that the default order is followed and make an educated guess but I don't like that.

Through the lengthy comment thread under the question you mentioned something interesting, that wasn't evident in your question.

the executable isn't dynamically linked as file command says: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped in this case, there's no a linker script, isn't? – The Mask

In this case the library contains the symbol table with all of the symbol offsets. This table includes section information. It will be processed by the linker when you compile your application. At that point it is your linker script that controls the order in which the .data and .bss sections are out put in.

If it is the default linker script, look it up. If it is custom, you should have access to it and can read it. If unsure elaborate here and we'll try and help :)

I myself have asked a question that is unrelated but offers example code of a linker script and some C code. In that linker script the .bss segment came after the .data segment.

Community
  • 1
  • 1
nonsensickle
  • 4,438
  • 2
  • 34
  • 61
1

You are looking at the program header information, whereas the section headers are probably what you need. There may be many sections contained within a program header and you cannot precisely infer the sizes and alignment requirements of the various sections.

To see the section headers, use:

readelf -S

Tom Gooding
  • 61
  • 2