> On 08 Jun 2015, at 10:50, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 7 June 2015 at 17:03, Liviu Ionescu <i...@livius.net> wrote: >> >>> On 07 Jun 2015, at 13:46, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> ... Some ELF files intended for embedded use have >>> a little self-initializing bit on the front that manually clears >>> their own .bss section, but that's not part of the ELF spec, and >>> QEMU will handle the other kind too. >> >> as I said, in the embedded world things are a bit different, there >> is no ELF loader, or you can consider the debugger as an ELF loader >> since it is reading the ELF file and programming the flash. >> >> but during this step it makes no sense to write/clear the RAM > > That depends on what the ELF file is.
yes and no. in this peculiar case, the problem is the simplistic approach in the QEMU ELF loader, that uses only the header defs, ignoring the detailed definitions in the separate sections. if you look carefully to the section in my file, you'll notice that the .bss section is **not** marked as LOAD (so the linker honoured the NOLOAD request), but the memory range in the header is marked as LOAD (I don't know the header structures, and the specs, but I would not exclude a linker bug). > If I were writing a debugger's > ELF loader code I would make it clear the bss area, because a > debugger is supposed to handle any ELF file you throw at it, > and following the ELF spec is trivial. for a debugger ELF loader, clearing the bss area would simply hide possible problems in the embedded startup code. for the startup code to clear the entire .bss area it requires correct linker scripts, which (unlike those used in the linux world, where you never deal with them), are part of each project and need to be manually maintained (a major problem for beginners), and it is usual to get linker scripts out of sync with the startup code requirement, and unstable embedded applications. if the startup is buggy, and does not clear the .bss, or does not copy .data from flash, the program might not run properly when standalone if it assumes that all variables start as 0, although it runs fine when started by the debugger, since the debugger cleared those variables. fortunately the ELF loader used in GDB does a good job in identifying the sections that need to be programmed (unlike the implementation used in QEMU). regards, Liviu
