From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54160 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtoLC-0006Tr-8J for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:07:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtoL6-0007bI-Sh for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:07:29 -0400 Received: from mail-ew0-f45.google.com ([209.85.215.45]:54797) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtoL6-0007b2-LH for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:07:24 -0400 Received: by ewy27 with SMTP id 27so1413990ewy.4 for ; Thu, 09 Sep 2010 14:07:23 -0700 (PDT) Date: Thu, 9 Sep 2010 23:07:19 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed Message-ID: <20100909210719.GA3280@laped.lan> References: <1281365033-6893-1-git-send-email-weil@mail.berlios.de> <4C891C9E.7030807@mail.berlios.de> <4C893168.7040909@mail.berlios.de> <4C8936BA.8030308@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , QEMU Developers On Thu, Sep 09, 2010 at 07:36:28PM +0000, Blue Swirl wrote: > On Thu, Sep 9, 2010 at 7:34 PM, Stefan Weil wrote: > > 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? > > Right, _end should be the last one in any case. I'll apply the patch. I'm not so sure that is the case. The load_symbols call throws away symbols that are not typed as functions. The filtering is done prior to the suggested size fixups so my guess is that _end is typically gone when the suggested size fixup is done. I'm not opposed to the patch though... Cheers