Ian Lance Taylor-3 wrote: > > "Jeffi Edward.J" <j.jeffi@xxxxxxxxxxx> writes: > >> Ian Lance Taylor-3 wrote: >>> >>> "Jeffi Edward.J" <j.jeffi@xxxxxxxxxxx> writes: >>> >>>> __sw_data_start = __code_end ; >>>> __sw_data_end = __sw_data_start + 1000; /* using constant size 1000 >>>> may >>>> leave hole or cause inadequate space (overlapping)for LMA of .data */ >>> >>> __sw_data_end = __sw_data_start + SIZEOF(.data); >> >> Thanks for the reply Ian. >> I tried SIZEOF(.data) too. The GNU linker again reports error since the >> .data section has not been defined at the calculation point. i.e again >> its a >> forward reference. >> >> Have I missed something in my script so that SIZEOF() is not working? >> Please >> suggest. > > Hmmm. That surprises me. But I would have to dig into the > implementation so see why that is happening. I assume that you are > using a reasonable recent version of the linker? > > If that doesn't work then I suppose I don't know if there is a good > way to leave a hole the exact size of the .data section. Usually > people don't care about that since the .data section comes at the end. > Actually it comes at the end for you, too. I guess the reason you > care is that you want to have the writable version of .data > immediately follow the read-only version in the address space. Most > people don't do that because the ROM and RAM are at different > addresses anyhow. > > You may need to use a two-phase link. Do a normal link to get the > size of the .data section, and then generate a linker script to do the > link you want. > > Ian > > Yes Ian. I'm using ld version 2.19.1. You are exactly correct. I would like to load the writable version of .data immediately following the read-only version in the address space. My entire application is at RAM only. But the reason for having two different regions for .data section is to have protection in image region(assumption). That why I would like to copy the .data from image region to different location and manipulate initialized global variables over there. ----------------------- 0 (__sw_image_start/__ram_start) text ----------------------- 1000 data (dont want to touch here) ----------------------- 1500 (__sw_image_end/__runtime_area_start) data (initialized global variable manipulation over here) ----------------------- 2000 bss ----------------------- 3000 heap ----------------------- 7000 (__ram_end) Since I'm porting the existing script (from diab) written for my application to GNU ld, I have to follow the semantics used in the existing script. Does it really make sense to have two .data sections within RAM itself? Since I'm very new to embedded domain, I'm not able to imagine indepth for the necessity of two .data sections in RAM. Will it cause any problem if I have only .data section (next to .text section, and LMA=VMA for .data)? How does having two .data sections add value to memory protection? Please coment on it. Thanks Ian for the suggestion of two phase linking. I'll work it out. -- View this message in context: http://old.nabble.com/How-to-dynamically-compute-space-for-LMA-of-.data-section-in-ld-script--tp27026793p27085974.html Sent from the gcc - Help mailing list archive at Nabble.com.
