From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13536 invoked by alias); 10 Jan 2015 21:23:11 -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 13525 invoked by uid 89); 10 Jan 2015 21:23:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 10 Jan 2015 21:23:09 +0000 Received: by mail-oi0-f48.google.com with SMTP id u20so16233433oif.7 for ; Sat, 10 Jan 2015 13:23:07 -0800 (PST) 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; bh=3dAJfgypu7N8leoxOeubvHNGbuicXeFwpgiUe3tDfjI=; b=fJqk3UPEy8Fgy4CzDdUtEhS+UEkkmMMNjmYyBKD/X+zKcoQ9vOarZLtBzEfY+6nmbH RUEcNcg7yssRPv/ksKO+o369Dmd896hgkWHxGjuW5Ggf6HCHY+pqvNTJ6dKPB9MuR4w4 DNtU4P1QSKMKOEW5MvZaHcF0rM3qkUxzgKH8r2oBfFf5DTSU7zZzOAUgF6MSSKkKE/ol 37zNokna9drUs2++VG/VKAg+IQhfxzaez/KaxJZ1B5tmqVrFGNxDP+rkntF9pCWDUQah RzJxY7Pd8PG6RH98zqDQnhTdw8+I4Ku5Q99b8A4a64/Gazjt0Hgdse7TUzzMnGaqZ/dz rsQw== X-Gm-Message-State: ALoCoQkjszGw9DUbazx/tbC/ezMLZpBTNqORWwzaXcwisfgE0KCUTpUQl+lFQl21BpiOiI7f9oyH MIME-Version: 1.0 X-Received: by 10.60.144.194 with SMTP id so2mr13313710oeb.65.1420924986955; Sat, 10 Jan 2015 13:23:06 -0800 (PST) Received: by 10.182.222.98 with HTTP; Sat, 10 Jan 2015 13:23:06 -0800 (PST) In-Reply-To: <54b07891.01b3c20a.2a7b.ffff9f96SMTPIN_ADDED_BROKEN@mx.google.com> References: <54ae4586.01e3440a.7b06.fffff844SMTPIN_ADDED_BROKEN@mx.google.com> <54AE605A.8050308@redhat.com> <54ae7f9f.c323460a.36ed.ffffff30SMTPIN_ADDED_BROKEN@mx.google.com> <54AE8914.4010507@redhat.com> <54ae911b.85e3440a.1d96.5ffdSMTPIN_ADDED_BROKEN@mx.google.com> <54AFB2E5.5080307@redhat.com> <54afff61.6790420a.0fa7.4f63SMTPIN_ADDED_BROKEN@mx.google.com> <54b07891.01b3c20a.2a7b.ffff9f96SMTPIN_ADDED_BROKEN@mx.google.com> Date: Sat, 10 Jan 2015 21:23:00 -0000 Message-ID: Subject: Re: [RFA PATCH 2/3] Add debug-stabs debug-dwarf and class option for pascal compiler From: Doug Evans To: Pierre Muller Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00266.txt.bz2 On Fri, Jan 9, 2015 at 4:55 PM, Pierre Muller wrote: >> Hi. >> This patch makes me uncomfortable. >> It's to a pascal specific file, so at least the discomfort is contained >> :-), >> but I wouldn't want this spreading. >> >> How to select debug information should be >> orthogonal to compilation language, >> and there are a myriad of ways to select what kind of dwarf debug info >> to get (with/without type units, with/without .gdb_index, with/without >> dwz, and so on). I have board files to help me drive the various >> combinations I'm interested in. This won't work if gdb.pascal/* >> starts hardcoding debug info into the test. >> >> Maybe there's a good reason to do it this way for pascal, >> but I need more data. > > Hi Doug, the reasons of this patch are: > > 1) the particular problem that the series fixes is strictly limited > to stabs debugging information. > > Thus to really test that this bug has been fixed, I need to compile > the test code using stabs debugging format (which I now realize > I did not do in the third part of the patch series). > > 2) the pascal language support tries to support both > GNU pascal compiler (aka GPC) and Free Pascal Compiler (aka FPC). > > These two compilers have very different options, > so the submitted patch purpose is to unify the selection of stabs versus dwarf > debug format independently from the used pascal compiler. > > For other pascal tests, only debug is used, which results in the default > format according to the target architecture and operating system. > > I hope that the explanations above are sufficient to ease your discomfort. Yeah, I figured those are the reasons, but I dunno. We're inventing something new here when existing mechanisms can already handle this. One *could* have the test be debug-format agnostic, and to test with stabs just do make check RUNTESTFLAGS=--target_board=stabs If you're using stabs you'll want to run the whole testsuite with stabs anyway. Plus if a compiler has a different spelling for -gstabs, one could have another board file for that compiler: you'll want to run the whole testsuite with that compiler anyway. make check RUNTESTFLAGS="gdb.pascal/*.exp --target_board=fpc-stabs" or some such. Obviously, by "whole testsuite" I mean the pascal parts. So that raises a question that may help guide the discussion. When testing with fpc, how do you run the testsuite? Do you just run the pascal subset, gdb.pascal/*.exp? Or do you run the WHOLE testsuite (i.e., gdb.*/*.exp), e.g., just a plain "make check" and expect the test harness to pick up fpc and DTRT. How do other languages handle this I wonder. I'm not totally opposed to this (I don't like to say "No."), but I'm still uncomfortable with the patch.