From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1874 invoked by alias); 2 Sep 2014 19:10:31 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 1861 invoked by uid 89); 2 Sep 2014 19:10:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f169.google.com Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 02 Sep 2014 19:10:20 +0000 Received: by mail-qc0-f169.google.com with SMTP id l6so7542672qcy.14 for ; Tue, 02 Sep 2014 12:10:18 -0700 (PDT) X-Received: by 10.229.62.129 with SMTP id x1mr58658786qch.16.1409685018249; Tue, 02 Sep 2014 12:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.50.34 with HTTP; Tue, 2 Sep 2014 12:09:57 -0700 (PDT) In-Reply-To: <540606F3.4030308@redhat.com> References: <540606F3.4030308@redhat.com> From: Crestez Dan Leonard Date: Tue, 02 Sep 2014 19:10:00 -0000 Message-ID: Subject: Re: [RFC 00/13] MIPS64 support To: Josh Stone Cc: Victor Kamensky , systemtap@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-q3/txt/msg00219.txt.bz2 On Tue, Sep 2, 2014 at 9:05 PM, Josh Stone wrote: > On 09/01/2014 06:47 AM, Crestez Dan Leonard wrote: >> I pushed an updated version of the mips patches to github: >> https://github.com/cdleonard/systemtap/commits/mips . The patches are >> ordered roughly by hackiness. The first 7 (up to and including >> b0c93e569acca2db978c7c557ad929fa041b8669) should be mostly >> uncontroversial and add basic mips support. Maybe we could get those >> in and then discuss the rest? I would very much like to merge this, I >> have no desire to maintain these patches separately. > > Ok, I'll review from there when I can, hopefully next week sometime. I > definitely understand not wanting to carry patches separately. But even > when it's merged, please understand that most of us Red Hat folks don't > work with mips machines, so we'll still have to rely on interested > parties like yourself to make sure it doesn't regress. Sounds great. Let me know if you would rather have me post those 7 patches as individual emails to the list. It's a little spammy but very useful for reviewing. >> The new release of elfutils 0.160 adds an API which can be used to >> avoid patch 7 "loc2c: Add Dwarf pointer to location_context". I'll >> rewrite that part, if it helps to get the patch into upstream. Other >> than that it's not clear that it's elfutils job to fix the other >> issues. I chose to restrict my patches to one project. > > I think the 0.160 API is a better way to go, especially since the main > Dwarf may not even be the right container for a given DIE when things > like .gnu_debugaltlink are considered. That shouldn't be an issue for > is_elf_mips64(), but might matter if we ever want loc2c to make other > queries on the Dwarf structure. > > But do guard that with _ELFUTILS_PREREQ please, so we don't force the > new minimum elfutils on everyone. Whatever mips-stap documentation you > write can explain under what circumstances this is really necessary. I will adjust my patch using the new elfutils API and avoid bumping elfutils globally. It's not strictly required for minimal mips support. -- Regards, Leonard