From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9jVL-000157-16 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:48:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9jV0-0001YR-Gm for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:48:34 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:59614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9jV0-0001Xr-8R for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:48:14 -0400 Received: by dadp14 with SMTP id p14so11579258dad.4 for ; Mon, 19 Mar 2012 13:48:12 -0700 (PDT) Sender: Richard Henderson Message-ID: <4F679B89.4000002@twiddle.net> Date: Mon, 19 Mar 2012 13:48:09 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1332185111-20739-1-git-send-email-rth@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] Use the GDB JIT debugging interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On 03/19/12 13:08, Peter Maydell wrote: > In system mode I get a backtrace like this: > > (gdb) bt > #0 helper_set_cp15 (env=0x80b41500, insn=3993505559, val=0) at > /home/pm215/src/qemu/qemu/target-arm/helper.c:1455 > #1 0x0101983d in ?? () > > ...is it possible to put in a useful string to replace that '??' > in line #1? I'm not sure. Maybe, with some more effort. GDB seems to be ignoring the elf-level symbol table, but reading the dwarf info. So it would be possible to add a minimal debug_info section as well. "Minimal" is irritatingly large though... > Any chance of some comments describing (a) what the limited debug > info does and what this does/doesn't support? [for instance it > doesn't seem to support doing a gdb backtrace while you're inside > the code_gen_prologue code] and (b) what the cpu-specific tcg backend > code needs to do/provide to support this? Putting this in tcg.c, perhaps? Sure. You're right that I don't try to handle code_gen_prologue. Getting that right is more difficult. Of course, I doubt we need to auto-generate the prologue code *at all*. Some statically generated assembler would do just as well, at which point we *could* add .cfi directives to handle that code. All the cpu-specific tcg backend needs to do is provide the contents of a .debug_frame section that describes the steady- state frame established by the prologue. Since the entire code_gen_buffer uses this same frame, the unwind is fixed for the entire buffer. r~