From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40149 invoked by alias); 28 Nov 2017 19:31:47 -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 40140 invoked by uid 89); 28 Nov 2017 19:31:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Nov 2017 19:31:46 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASJTUYB118205 for ; Tue, 28 Nov 2017 14:31:44 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ehc8g58mh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Nov 2017 14:31:44 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 28 Nov 2017 19:31:42 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 28 Nov 2017 19:31:40 -0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vASJVe5O19202058; Tue, 28 Nov 2017 19:31:40 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F033FAE056; Tue, 28 Nov 2017 19:24:47 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5336AE045; Tue, 28 Nov 2017 19:24:47 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.164.153.34]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 28 Nov 2017 19:24:47 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id B613CD80317; Tue, 28 Nov 2017 20:31:39 +0100 (CET) Subject: Re: [PATCH 1/4] Split up s390-linux-tdep.c into two files To: prudo@linux.vnet.ibm.com (Philipp Rudo) Date: Tue, 28 Nov 2017 19:31:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, arnez@linux.vnet.ibm.com (Andreas Arnez) In-Reply-To: <20171128103442.7a4a5225@ThinkPad> from "Philipp Rudo" at Nov 28, 2017 10:34:42 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17112819-0020-0000-0000-000003D19AA5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112819-0021-0000-0000-000042670379 Message-Id: <20171128193139.B613CD80317@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-28_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280261 X-SW-Source: 2017-11/txt/msg00743.txt.bz2 Phillip Rudo wrote: > I think it is best when we defer the question whether the kernel target should > use s390-linux-tdep till after the split is final. Then we have a stable base > we can use. Sure. > Is there anything in s390-tdep.c left you think that should be moved? > Otherwise ... As discussed earlier, I think the ABI-related routines are fine to move to the generic part, since they explicitly check tdep->abi. Given that, I think the only stuff that really needs to be Linux-specific is the syscall handling (including interrupted system call restart), the register sets, and the signal frame handling. That would be about these routines: s390_write_pc (struct regcache *regcache, CORE_ADDR pc) s390_supply_tdb_regset (const struct regset *regset, struct regcache *regcache, s390_iterate_over_regset_sections (struct gdbarch *gdbarch, s390_core_read_description (struct gdbarch *gdbarch, s390_sigtramp_frame_unwind_cache (struct frame_info *this_frame, s390_sigtramp_frame_this_id (struct frame_info *this_frame, s390_sigtramp_frame_prev_register (struct frame_info *this_frame, s390_sigtramp_frame_sniffer (const struct frame_unwind *self, s390_linux_get_syscall_number (struct gdbarch *gdbarch, s390_all_but_pc_registers_record (struct regcache *regcache) s390_canonicalize_syscall (int syscall, enum s390_abi_kind abi) s390_linux_syscall_record (struct regcache *regcache, LONGEST syscall_native) s390_linux_record_signal (struct gdbarch *gdbarch, struct regcache *regcache, s390_init_linux_record_tdep (struct linux_record_tdep *record_tdep, Everything else can move to s390-tdep.c > ... i'll move the regsets and s390_register_call_saved to s390-linux-tdep. The > way the latter currently is implemented doesn't support any other OS than Linux. s390_register_call_saved is really just one of the ABI routines and can stay with the rest of them. If we ever need to support different ABIs, we can always extend the value set of tdep->abi. > My plan is to add the usage of OSABI on top of the split as is (with the small > changes described above). This makes it easier to find bugs i might introduce > which would otherwise be cloaked by the split. Any rejections? Hmm. If you want to split this, I'd prefer if you were to first add the OSABI routines *while keeping everything in one file* and then split the files. (The newly added OSABI stuff will remain in s390-linux-tdep.c anyway). > My problem aren't the tdep->have_* fields but the corresponding variables > defined in s390_gdbarch_init. With them all there are dependencies all over the > function. It looks to me that there's a first part that *sets* those values, and then a couple of later uses that determine the pseudo register numbers. That latter part can use the tdep->have_ flags instead (they are already set at this point) and can move to the generic file. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com