From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6160 invoked by alias); 21 Mar 2011 16:00:08 -0000 Received: (qmail 5886 invoked by uid 22791); 21 Mar 2011 16:00:01 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Mar 2011 15:59:42 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/48220] New: DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 21 Mar 2011 16:35:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg02235.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220 Summary: DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned@gcc.gnu.org ReportedBy: jakub@gcc.gnu.org I haven't thought too much about register window issues when designing this extension, so it would be good to decide what exactly to do for such targets. Let's start with some testcases: __attribute__((noinline, noclone)) void fn1 (long int x, long int y, long int z) { asm volatile ("" : : "r" (x), "r" (y), "r" (z) : "memory"); } __attribute__((noinline, noclone)) long int fn2 (long int a, long int b, long int c) { long int q = 2 * a; fn1 (5, 6, 7); return 0; } long int fn3 (long int x, long int (*fn4) (long int *)) { long int v, w, w2, z; w = (*fn4) (&w2); v = (*fn4) (&w2); z = fn2 (1, v + 1, w); { int v1 = v + 4; z += fn2 (w, v * 2, x); } return z; } int main (void) { return 0; } and testcase from http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html While GDB support has been written for these extensions on http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval I bet it hasn't been tested on sparc/ia64/and other register window targets yet. For SPARC, my preference would be if DW_OP_GNU_entry_value contained the output regs, after all when it is defined as value at the start of the function (== put a breakpoint on the very first insn and use value of that register), then the parameters are passed in %o[0-5] registers rather than %i[0-5]. And I guess the gdb changes should then magically work when using DW_TAG_call_site info - it will just look up the same registers with no translation. OT, seems if we wanted to be exact we'd need to model the register window save/restrore insns in var-tracking adjust_insn and start in vt_add_function_parameter with the outgoing regs instead of incoming that are in DECL_INCOMING_RTL. Current SVN trunk uses %i* instead of %o* in DW_OP_GNU_entry_value operands and %o* registers in DW_AT_location of DW_OP_GNU_entry_value. IA-64 is more challenging. On SPARC just the save/restore insns are relevant to the register windows, while on IA-64 both br{,l}.call and alloc insns. With the definition that DW_OP_GNU_entry_value should be defined as put a breakpoint on the very first insn in a function, remember register values there I'd say thus that DW_OP_GNU_entry_value should reference r32/r33/etc. regs. The question is what should be used in DW_AT_location of DW_TAG_GNU_call_site_parameter. Either it can be the state on the br.call insn itself (which would mean they are the outN registers mapped accordinly to the hard register numbers given the current alloc insn), or after the call insn is executed (then we'd need to map the outN registers to the inNs). The first option would mean more work for the debugger on IA-64, it would need to map the outNs to inS, but perhaps is more in line with the proposal that DW_TAG_GNU_call_site_parameter lists the location at the call. And it would require no changes to GCC. The other option would mean less work for the debugger, but GCC would need to map the parameter registers in prepare_call_arguments using INCOMING_REGNO for ia64. If we go this route, the question is if registers mentioned in DW_AT_GNU_call_site_value etc. shouldn't be remapped too, so I very much prefer the first variant for IA-64 if it can be implemented.