Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><code>from file position 0x1000</code> means what it says. You have it in the dump:</p> <pre><code>[Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 1] .text PROGBITS c5000000 001000 5ac13e 00 AX 0 0 4096 </code></pre> <p>It's where the <code>.text</code> section starts in the file, at offset <code>0x1000</code>.</p> <blockquote> <p>But one thing we can see here .text section is greater than DRAM end address</p> </blockquote> <p>Nope, it's not <em>greater</em> (not in the sense of <em>bigger</em>, at least), it's compiled in the expectation that it'll be loaded at address <code>0xc5000000</code> in the memory.</p> <blockquote> <p>so image should not be loded properly though we are not getting any error after loading first section it keeps on loading other sections</p> </blockquote> <p>The image can be loaded anywhere, it's just data for the purpose of loading.</p> <p>OTOH, if <code>loading section to address 0xc5000000</code> means what it says, the file gets loaded into nowhere since your RAM ends at <code>0x7fffffff</code>.</p> <blockquote> <p>but after this message it hangs.</p> </blockquote> <p>And that's expected. Machine code is rarely position-independent and so if you load it at a location different from where it's supposed to be loaded, it'll not work. Or if it doesn't even get loaded, then what are you going to execute? Garbage.</p> <blockquote> <p>Is there any way to set these section addresses before compilation??</p> </blockquote> <p>Depending on the system you may have one of the two below options or both:</p> <ul> <li>set up page translation in such a way that virtual addresses from <code>0xc5000000</code> and up map to physical addresses from <code>0x5000000</code> and up for the entire program</li> <li>find the linker script that your compiler is using and change the initial section address from <code>0xc5000000</code> to <code>0x5000000</code>, google this up, see compiler/linker documentation</li> </ul> <p>Also, it's a bit odd that the entry point is at <code>0x5000000</code>. Not that this is necessarily wrong, it's just that it's rarely the case. I'd make sure that the <code>start</code> label (or <code>_start</code> or whatever it is) indeed receives the same address as the beginning of the <code>.text</code> section. If, for some reason, it's not the case, there's something wrong either with the linker script or the compiler/linker command-line options or with the loader.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload