From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24908 invoked by alias); 9 Aug 2007 18:19:17 -0000 Received: (qmail 24726 invoked by uid 22791); 9 Aug 2007 18:19:16 -0000 X-Spam-Check-By: sourceware.org Received: from hu-out-0506.google.com (HELO hu-out-0506.google.com) (72.14.214.232) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Aug 2007 18:19:05 +0000 Received: by hu-out-0506.google.com with SMTP id 22so555137hug for ; Thu, 09 Aug 2007 11:19:02 -0700 (PDT) Received: by 10.82.186.5 with SMTP id j5mr3951938buf.1186683541952; Thu, 09 Aug 2007 11:19:01 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Thu, 9 Aug 2007 11:19:01 -0700 (PDT) Message-ID: <52d7a73d0708091119n3d480b6bl9bacbc588f6dcbfb@mail.gmail.com> Date: Thu, 09 Aug 2007 18:19:00 -0000 From: "Ti Strga" To: binutils@sourceware.org Subject: Using FILL(n) or =FILLEXP in linker scripts MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00131.txt.bz2 Hello. The super short version of our question is: are FILL/FILLEXPs actually written out to the ELF file, like initialized data? Or are they just stored as a "do this at startup", like .bss sections? We are using a custom linker script with GNU ld 2.17 targeting powerpc-elf (embedded, no OS yet, bare metal, etc). It started as a copy of the stock elf32ppc.x script, heavily modified by somebody who does not really know compilers and is learning about linker scripts as he goes (me). Under normal conditions, we have some output sections listed, and after the sections we define some symbols to delimit two subsequent "chunks" of memory. Example with internal confusing names replaced: ..... .last_example_block : { ....... __last_example_block_end = .; } > ram /* Chunk one runs from the end of the last block to here. */ . = . + _CHUNK_ONE_SIZE; . = ALIGN(16); __chunk_one_top = .; /* Chunk two follows, with its own markers. */ __chunk_two_bottom = .; . = . + _CHUNK_TWO_SIZE; . = ALIGN(16); __chunk_two_top = .; That all works fine. (Based on ld.info, I think the ALIGN statement is supposed to be able to be merged with the "sizing" statement preceding it, but we couldn't get that syntax to work. No big deal.) Here's the problem: for debugging, we'd like to occasionally fill either of those "chunks" with a constant pattern; typically, the second of the two chunks. Fill expressions only work within section blocks according to the manual, so we replace the last bit of that script with: .internal_chunk_two : { FILL(0xDEADBEEF) /* attempt one */ __chunk_two_bottom = .; . = . + _CHUNK_TWO_SIZE; . = ALIGN(16); __chunk_two_top = .; } > ram =0xDEADBEEF /* attempt two */ Neither FILL nor FILLEXP work here. We get two things wrong: first, the ELF file as written to disk doesn't contain our fill pattern. The file *is* much larger, as one would expect -- it's writing out the contents of that chunk instead of just storing the endpoints. But the contents are all explicit zeros. The second problem is that the two chunks overlap. Using the example names, the new .internal_chunk_two is being placed immediately after .last_example_block, and so __last_example_block_end and __chunk_two_bottom have the same address. (The first "chunk" is typically small, so it ends up actually *inside* the second one, with ensuing hilarity.) Our questions: (1) What are we doing wrong with the fill expression? (2) Shouldn't the line ". = . + _CHUNK_ONE_SIZE;" have moved the location counter forward in memory for the references in .internal_chunk_two? We seem to have worked around the issue by using "__chunk_two_bottom = __chunk_one_top;" in that output section, but I don't know if that's the correct solution, or why the first way isn't working. Any light which anyone could shed would be very appreciated. Ti