From: Doug Evans <dje@google.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Nicolas Blanc <nicolas.blanc@intel.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH v12 4/5] Function is_elf_target.
Date: Wed, 17 Jul 2013 19:47:00 -0000 [thread overview]
Message-ID: <CADPb22RYv04MvvzNgLFXK6dG12a0ab2d1-ukSY+5Rfnk1r5zNA@mail.gmail.com> (raw)
In-Reply-To: <201307171843.r6HIhWEQ006115@glazunov.sibelius.xs4all.nl>
On Wed, Jul 17, 2013 at 11:43 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> From: Nicolas Blanc <nicolas.blanc@intel.com>
>> Date: Wed, 17 Jul 2013 18:27:34 +0200
>>
>> 2013-17-07 Nicolas Blanc <nicolas.blanc@intel.com>
>>
>> gdb/testsuite
>> * lib/gdb.exp (is_elf_target): New function.
>>
>> Signed-off-by: Nicolas Blanc <nicolas.blanc@intel.com>
>
> That's a very incomplete list.
>
> I think a better solution is needed. Instead of whitelisting targets
> for what is basically the default, blacklisting targets that aren't
> ELF would be a better approach.
There are plenty of places in the testsuite that don't do an
exhaustive check for whether the system is elf.
Instead, they just cover enough cases that we care about.
Consider testsuite/lib/dwarf.exp:dwarf2_support
ortestsuite/lib/gdb.exp:skip_shlib_tests.
[I realize there's also some blacklist-using functions, e.g. skip_cplus_tests.
But for the task at hand, I'm ok with the whitelist since that is what
the testsuite uses today,
except that it replicates this list every time, with some apparent drift.
E.g., gdb.base/dup-sect.exp and gdb.python/py-section-script.exp.]
How about renaming the function to is_known_elf_target?
[Though for consistency's sake one might then want to rename
dwarf_support to known_dwarf_support.
Thus I prefer is_elf_target, but if necessary is_known_elf_target works too.]
One thing one could wish is requiring all places that currently
hardcode this list to be updated to use this function.
grepping for "istarget.*-elf" doesn't have that many hits and the spu
hits can be ignored.
next prev parent reply other threads:[~2013-07-17 19:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 16:28 [PATCH v12 0/5] remove-symbol-file & add-symbol-file Nicolas Blanc
2013-07-17 16:27 ` [PATCH v12 1/5] New remove-symbol-file command Nicolas Blanc
2013-07-17 16:27 ` [PATCH v12 2/5] Documentation for the " Nicolas Blanc
2013-07-17 17:02 ` Eli Zaretskii
2013-07-17 16:27 ` [PATCH v12 4/5] Function is_elf_target Nicolas Blanc
2013-07-17 18:43 ` Mark Kettenis
2013-07-17 19:47 ` Doug Evans [this message]
2013-07-17 16:28 ` [PATCH v12 3/5] 'add-symbol-file' should update the current target sections Nicolas Blanc
2013-07-26 19:10 ` Luis Machado
2013-07-17 16:28 ` [PATCH v12 5/5] Test adding and removing a symbol file at runtime Nicolas Blanc
2013-07-17 18:53 ` Mark Kettenis
2013-07-18 12:52 ` Blanc, Nicolas
2013-07-18 13:28 ` Mark Kettenis
2013-07-18 16:05 ` Blanc, Nicolas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADPb22RYv04MvvzNgLFXK6dG12a0ab2d1-ukSY+5Rfnk1r5zNA@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=nicolas.blanc@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox