From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96341 invoked by alias); 26 Jan 2016 18:12:43 -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 96319 invoked by uid 89); 26 Jan 2016 18:12:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=undocumented, 0x80000000, 24bit, Hx-languages-length:2209 X-HELO: e06smtp11.uk.ibm.com Received: from e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 26 Jan 2016 18:12:41 +0000 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Jan 2016 18:12:38 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 26 Jan 2016 18:12:37 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9DA6A1B0805F for ; Tue, 26 Jan 2016 18:12:44 +0000 (GMT) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0QICbJA4915684 for ; Tue, 26 Jan 2016 18:12:37 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0QICaEH020087 for ; Tue, 26 Jan 2016 13:12:37 -0500 Received: from oc1027705133.ibm.com (dyn-9-152-212-180.boeblingen.de.ibm.com [9.152.212.180]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0QICauW020072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 13:12:36 -0500 From: Andreas Arnez To: Marcin =?utf-8?Q?Ko=C5=9Bcielnicki?= Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/8] gdb/s390: Fill write_guessed_tracepoint_pc hook. References: <1453637529-26972-1-git-send-email-koriakin@0x04.net> <1453637529-26972-3-git-send-email-koriakin@0x04.net> Date: Tue, 26 Jan 2016 18:12:00 -0000 In-Reply-To: <1453637529-26972-3-git-send-email-koriakin@0x04.net> ("Marcin \=\?utf-8\?Q\?Ko\=C5\=9Bcielnicki\=22's\?\= message of "Sun, 24 Jan 2016 13:12:03 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012618-0041-0000-0000-0000074B8B07 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00661.txt.bz2 On Sun, Jan 24 2016, Marcin Ko=C5=9Bcielnicki wrote: > diff --git a/gdb/s390-linux-tdep.c b/gdb/s390-linux-tdep.c > index e827684..c4d25d2 100644 > --- a/gdb/s390-linux-tdep.c > +++ b/gdb/s390-linux-tdep.c > @@ -167,6 +167,22 @@ s390_write_pc (struct regcache *regcache, CORE_ADDR = pc) > regcache_cooked_write_unsigned (regcache, S390_SYSTEM_CALL_REGNUM, 0= ); > } >=20=20 > +static void > +s390_write_guessed_tracepoint_pc (struct regcache *regcache, CORE_ADDR p= c) Please add documentation for this function, as described here: https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Docume= nt_Every_Subprogram Note that this was not always done in the past; thus there are still many undocumented functions in this file. But for new functions we should stick to it. > +{ > + struct gdbarch *gdbarch =3D get_regcache_arch (regcache); > + struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); > + int sz =3D register_size (gdbarch, S390_PSWA_REGNUM); > + gdb_byte *reg =3D (gdb_byte *) alloca (sz); > + > + /* 31-bit PSWA needs high bit set. */ > + if (tdep->abi =3D=3D ABI_LINUX_S390) > + pc |=3D 0x80000000; This is done differently in s390_pseudo_register_write: the high bit is copied from the original PSWA. Of course, this only makes a difference if a program ever switches to 24-bit mode (yikes). I just wonder whether both cases should be treated the same, or whether there's good reason not to. > + > + store_unsigned_integer (reg, sz, gdbarch_byte_order (gdbarch), pc); > + regcache_raw_supply (regcache, S390_PSWA_REGNUM, reg); > +} > + >=20=20 > /* DWARF Register Mapping. */ >=20=20 > @@ -7857,6 +7873,7 @@ s390_gdbarch_init (struct gdbarch_info info, struct= gdbarch_list *arches) > s390_iterate_over_regset_sections); > set_gdbarch_cannot_store_register (gdbarch, s390_cannot_store_register= ); > set_gdbarch_write_pc (gdbarch, s390_write_pc); > + set_gdbarch_write_guessed_tracepoint_pc (gdbarch, s390_write_guessed_t= racepoint_pc); > set_gdbarch_pseudo_register_read (gdbarch, s390_pseudo_register_read); > set_gdbarch_pseudo_register_write (gdbarch, s390_pseudo_register_write= ); > set_tdesc_pseudo_register_name (gdbarch, s390_pseudo_register_name);