From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31967 invoked by alias); 27 Oct 2014 16:40:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31955 invoked by uid 89); 27 Oct 2014 16:40:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-lb0-f174.google.com Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 27 Oct 2014 16:40:16 +0000 Received: by mail-lb0-f174.google.com with SMTP id p9so6162840lbv.33 for ; Mon, 27 Oct 2014 09:40:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BF51mjaAT1x2TsTXoyVD3kzT/oY3EvvRbuf0zgBnWNA=; b=Zed0Br2Vr9ocS1xQhudphPSgciZoG6BxM6uV2SR3GaYQmA1r6F4YYo4rkRrNqYn2C6 4qvsj4mgVI2LKqPUQMwFULA01vbtZcq88AyDe42a66pEavISq/XqwsYUXOxToVyJf4S1 vaXiS2wO0Z5Da2iXY72iCNP8AjvNnto1IuYPfL0bWTK6fg/MmSeSDX+I4HK1UdVZjj/h y95d62vxYgb6Vd+IekiligsGF2l/0GoqNGVlEB2lYB3cPhdlPmMXmpY431bAb7iVFXUc 5/fW2PdXg4cMRs30Z5gjIEIege07YewdN5D8kU2Z2vMIIlXTmjRZ2WDN1KQ84tuyntdy iH6A== X-Gm-Message-State: ALoCoQl0WlZtKtsME51gb6t7ryqlFfcKLoQ4jYCdxZXamYBcUQ6YQERqLk5MJzjm5amT9GJ+VrdF MIME-Version: 1.0 X-Received: by 10.112.166.1 with SMTP id zc1mr4821504lbb.90.1414428012595; Mon, 27 Oct 2014 09:40:12 -0700 (PDT) Received: by 10.112.59.129 with HTTP; Mon, 27 Oct 2014 09:40:12 -0700 (PDT) In-Reply-To: <544AD3E1.4030003@redhat.com> References: <1413986485-4673-1-git-send-email-martin.galvan@tallertechnologies.com> <544822D6.8020606@redhat.com> <544828BB.9040900@redhat.com> <544A68B1.9000909@redhat.com> <544AB1E5.8030509@redhat.com> <544AD3E1.4030003@redhat.com> Date: Mon, 27 Oct 2014 16:40:00 -0000 Message-ID: Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue. From: Martin Galvan To: Pedro Alves Cc: gdb-patches@sourceware.org, Doug Evans , Eli Zaretskii , Ulrich Weigand , Daniel Gutson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-10/txt/msg00738.txt.bz2 On Fri, Oct 24, 2014 at 7:34 PM, Pedro Alves wrote: > You can set breakpoints before running the program: > > (top-gdb) b *main > Breakpoint 3 at 0x45ed30: file /home/pedro/gdb/mygit/build/../src/gdb/gdb= .c, line 25. > (top-gdb) b main > Breakpoint 4 at 0x45ed3f: file /home/pedro/gdb/mygit/build/../src/gdb/gdb= .c, line 28. > > That offset is your "prologue", however meaningful that is. Indeed. However, setting breakpoints just to parse that output is ugly :) > I think we still don't know what you're trying to do, only > a bit of _how_ you're trying to do it. :-) It makes it > harder to understand the use case, and to suggest solutions. In my case, I'm working on a Gdb-based fault injection machine which will select some random PC from a given program, check if local variables are visible at that point, drive the target to said point and corrupt the contents of said variables. If I had a way to know at which point a function's arguments will be ready to be used, the attacks could be more effective: it's useless to corrupt the temporary value the args have before they're initialized in the function's prologue. However, as the PC is selected at random and it won't always target the prologue, I wouldn't mind a few "missed" attacks if you really don't want to include the prologue function. The epilogue is a bit trickier: after the stack frame is destroyed, Gdb will show the variables' addresses as pointing to other places in the stack. If I were to corrupt those places, I could change the value of the previous PC (which was stored as we entered the function), which would make the program crash. While that seems like a desirable thing, it's not for what I'm trying to test with this particular behavior. >> I looked up the approach GDB takes when setting a breakpoint at a >> function name. From what I saw it appears to be similar as the >> "optimistic" path from in_prologue (that is, using symtab and line >> info). I guess that makes sense since setting a breakpoint by function >> name by definition requires us to have debugging info. > > If you need access to local variables, then you're already > relying on debug info. Yes, but here's the thing: what in_prologue (and handle_step_into_function, etc) do is taking the first address of a function, getting its line number info and assuming the prologue ends at the last address covered by that line. This is based on the assumption that the compiler will mark the prologue as its own "line". What confused me initially was that in_prologue had what appeared to be a check for the case where a function would have all its code on a single line. If that check didn't pass, it called gdbarch_skip_prologue (which is what we're trying to avoid). I didn't see something like that for the breakpoint setting code, so I tried doing "break myFunction", where myFunction is defined in a single line. It worked as expected: the breakpoint was still set at the end of the prologue. I'm not certain, however, of how would this work on hand-written assembly or the case where a compiler would schedule an instruction from the function body to be inside the prologue (would it mark that instruction as part of the first "line"?). The bottom line is: I'm willing to drop the prologue API function, as it's not essential to me particularly, but if we were to keep it we'd have to require the function_start argument. I really need to keep the epilogue (or perhaps I should say "stack destroyed"?) function, though. --=20 Mart=C3=ADn Galv=C3=A1n Software Engineer Taller Technologies Argentina San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: 54 351 4217888 / +54 351 4218211