From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39727 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtmoY-0005u1-MV for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:29:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtmoX-0000Cm-B6 for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:29:42 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:38831) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtmoX-0000Ch-8I for qemu-devel@nongnu.org; Thu, 09 Sep 2010 15:29:41 -0400 Received: by qwi4 with SMTP id 4so3051qwi.4 for ; Thu, 09 Sep 2010 12:29:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C893168.7040909@mail.berlios.de> References: <1281365033-6893-1-git-send-email-weil@mail.berlios.de> <4C891C9E.7030807@mail.berlios.de> <4C893168.7040909@mail.berlios.de> From: Blue Swirl Date: Thu, 9 Sep 2010 19:29:18 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Anthony Liguori , QEMU Developers 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 >>>> =C2=A0wrote: >>>> >>>>> >>>>> 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 >>>>> --- >>>>> =C2=A0hw/elf_ops.h | =C2=A0 =C2=A05 +++++ >>>>> =C2=A01 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, >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0syms =3D qemu_realloc(syms, nsyms * sizeof= (*syms)); >>>>> >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0qsort(syms, nsyms, sizeof(*syms), glue(sym= cmp, SZ)); >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i< =C2=A0nsyms - 1; i++) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (syms[i].st_size =3D=3D= 0) { >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syms[i].st_s= ize =3D syms[i + 1].st_value - >>>>> syms[i].st_value; >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>>>> >>>> >>>> The size of the last symbol is not guesstimated, it could be assumed >>>> to be _etext - syms[nsyms].st_value. >>>> >>>> >>>>> >>>>> =C2=A0 =C2=A0} else { >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0qemu_free(syms); >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0syms =3D 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 o= nly > 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?