This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA PATCH 2/3] Add debug-stabs debug-dwarf and class option for pascal compiler
- From: Doug Evans <dje at google dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Sat, 10 Jan 2015 13:23:06 -0800
- Subject: Re: [RFA PATCH 2/3] Add debug-stabs debug-dwarf and class option for pascal compiler
- Authentication-results: sourceware.org; auth=none
- References: <54ae4586 dot 01e3440a dot 7b06 dot fffff844SMTPIN_ADDED_BROKEN at mx dot google dot com> <54AE605A dot 8050308 at redhat dot com> <54ae7f9f dot c323460a dot 36ed dot ffffff30SMTPIN_ADDED_BROKEN at mx dot google dot com> <54AE8914 dot 4010507 at redhat dot com> <54ae911b dot 85e3440a dot 1d96 dot 5ffdSMTPIN_ADDED_BROKEN at mx dot google dot com> <54AFB2E5 dot 5080307 at redhat dot com> <54afff61 dot 6790420a dot 0fa7 dot 4f63SMTPIN_ADDED_BROKEN at mx dot google dot com> <CADPb22TZH+Ab6xLi_pKspY1xeh76Ms7G5r2r_KcMEHn2pWd2tw at mail dot gmail dot com> <54b07891 dot 01b3c20a dot 2a7b dot ffff9f96SMTPIN_ADDED_BROKEN at mx dot google dot com>
On Fri, Jan 9, 2015 at 4:55 PM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> 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.