From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50370 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtmtB-00004t-0x for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:34:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Otmt5-00019b-FL for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:34:28 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:56189) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Otmt5-00019L-33 for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:34:23 -0400 Message-ID: <4C8936BA.8030308@mail.berlios.de> Date: Thu, 09 Sep 2010 21:34:18 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed References: <1281365033-6893-1-git-send-email-weil@mail.berlios.de> <4C891C9E.7030807@mail.berlios.de> <4C893168.7040909@mail.berlios.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , QEMU Developers Am 09.09.2010 21:29, schrieb Blue Swirl: > On Thu, Sep 9, 2010 at 7:11 PM, Stefan Weil wrote: > >> Am 09.09.2010 20:44, schrieb Blue Swirl: >> >>> On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil wrote: >>> >>>> Am 11.08.2010 18:21, schrieb Blue Swirl: >>>> >>>>> On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil >>>>> wrote: >>>>> >>>>> >>>>>> Symbols with a size of 0 are unusable for the disassembler. >>>>>> >>>>>> Example: >>>>>> >>>>>> While running an arm linux kernel, no symbolic names are >>>>>> used in qemu.log when the cpu is executing an assembler function. >>>>>> >>>>>> >>>>> That is a problem of the assembler function, it should use '.size' >>>>> directive like what happens when C code is compiled. And why just ARM? >>>>> >>>>> >>>>> >>>>>> Assume that the size of such symbols is the difference to the >>>>>> next symbol value. >>>>>> >>>>>> Signed-off-by: Stefan Weil >>>>>> --- >>>>>> hw/elf_ops.h | 5 +++++ >>>>>> 1 files changed, 5 insertions(+), 0 deletions(-) >>>>>> >>>>>> diff --git a/hw/elf_ops.h b/hw/elf_ops.h >>>>>> index 27d1ab9..0bd7235 100644 >>>>>> --- a/hw/elf_ops.h >>>>>> +++ b/hw/elf_ops.h >>>>>> @@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr >>>>>> *ehdr, int fd, int must_swab, >>>>>> syms = qemu_realloc(syms, nsyms * sizeof(*syms)); >>>>>> >>>>>> qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ)); >>>>>> + for (i = 0; i< nsyms - 1; i++) { >>>>>> + if (syms[i].st_size == 0) { >>>>>> + syms[i].st_size = syms[i + 1].st_value - >>>>>> syms[i].st_value; >>>>>> + } >>>>>> + } >>>>>> >>>>>> >>>>> The size of the last symbol is not guesstimated, it could be assumed >>>>> to be _etext - syms[nsyms].st_value. >>>>> >>>>> >>>>> >>>>>> } else { >>>>>> qemu_free(syms); >>>>>> syms = NULL; >>>>>> -- >>>>>> 1.7.1 >>>>>> >>>>> >>>> >>>> The patch is still missing in qemu master. >>>> From the two feedbacks I did not read that anything needs to be changed. >>>> Was I wrong, or can it be applied? >>>> >>> Please fix the last symbol. Either we should fix all symbols or none, >>> half fixed (OK, practically all) is not so great. >>> >> >> The last symbol is one of several thousands, and most symbols don't need a >> fix, >> so with my fix more than 99.9 or even 99.99 percent of all symbols are ok >> :-) >> If the last symbol happens to be wrong, there is still a high probability >> that >> nobody will notice this because it is unused by QEMU. The problem I faced >> with >> QEMU's disassembly came from symbols with an address followed by code. >> Is there any code after the last symbol? I don't expect that. In a sorted >> list >> of symbols from the text segment, _etext should be the last symbols! >> >> I think that the small chance of a missing fix for the last symbol is in no >> relation >> to the code needed. >> >> Even worse, I have no simple formula to guess a valid value for the last >> symbol. >> The formula you suggested (with the corrections I wrote in my reply) is only >> ok >> if the last symbol is in the text segment. Usually there are also symbols >> for data >> in other segments, and in many cases these segments are located after the >> text segment. In these cases the last symbol is not located in the text >> segment >> which makes guesses of its size much more complicated. >> > How about using _end then? > > Wouldn't _end be the last symbol then?