From: Joel Brobecker <brobecker@adacore.com>
To: Doug Evans <dje@google.com>
Cc: Tom Tromey <tromey@redhat.com>, Pedro Alves <palves@redhat.com>,
gdb-patches@sourceware.org
Subject: Re: RFA: handle "MiniDebuginfo" section
Date: Wed, 14 Nov 2012 22:12:00 -0000 [thread overview]
Message-ID: <20121114221211.GA3790@adacore.com> (raw)
In-Reply-To: <20643.62177.106208.211209@ruffy2.mtv.corp.google.com>
> 1) Being more of a minimalist when it comes to adding new stuff, and
> applying "It's easier to relax restrictions than impose them after the
> fact." it would be easy enough to restrict the section to being an
> (lzma-compressed) ELF file (and equally easy to relax the restriction
> if someone ever presented a compelling reason to support it). Sure,
> we *can* support COFF, etc. but that doesn't, to me, mean we *should*.
> Does Redhat have a *formal* spec of .gnu_debugdata that says COFF,
> etc. is supported. [If that's the case then my point is moot, but I
> couldn't find any such formal spec.]
I am still trying to understand exactly what you mean by the above.
Sorry for being dense! can you clarify a bit? As said on IRC, it seems
to me that you want to disable this feature on targets that use non-ELF
object files (which would require some extra code just to make sure we
activate this only if the object file is ELF). But our discussion on
IRC seems to indicate that you're proposing something else...
--
Joel
next prev parent reply other threads:[~2012-11-14 22:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 17:33 Tom Tromey
2012-11-09 18:07 ` Eli Zaretskii
2012-11-09 18:13 ` Pedro Alves
2012-11-09 21:28 ` Tom Tromey
2012-11-13 12:56 ` Pedro Alves
2012-11-13 15:26 ` Pedro Alves
2012-11-13 18:32 ` Tom Tromey
2012-11-09 18:23 ` Joel Brobecker
2012-11-09 18:53 ` Pedro Alves
2012-11-09 19:13 ` Tom Tromey
2012-11-12 16:04 ` Tom Tromey
2012-11-12 17:04 ` Joel Brobecker
2012-11-12 18:24 ` Tom Tromey
2012-11-12 16:28 ` Tom Tromey
2012-11-13 18:36 ` Tom Tromey
2012-11-13 18:42 ` Eli Zaretskii
2012-11-13 19:12 ` Pedro Alves
2012-11-13 20:57 ` Tom Tromey
2012-11-14 16:13 ` Tom Tromey
2012-11-14 16:19 ` Pedro Alves
2012-11-14 16:59 ` Tom Tromey
2012-11-14 19:37 ` Doug Evans
2012-11-14 22:12 ` Joel Brobecker [this message]
2012-11-15 11:18 ` Pedro Alves
2012-11-16 19:51 ` Tom Tromey
2012-11-19 14:41 ` Pedro Alves
2012-11-26 19:21 ` Tom Tromey
2012-11-26 22:24 ` Andrew Pinski
2012-11-27 2:23 ` Tom Tromey
2012-11-29 19:19 ` Ulrich Weigand
2012-11-29 19:23 ` Tom Tromey
2012-11-29 19:33 ` Ulrich Weigand
2012-11-29 20:51 ` Tom Tromey
2012-11-30 14:05 ` Ulrich Weigand
2012-11-30 20:59 ` Tom Tromey
2012-12-05 17:09 ` Ulrich Weigand
2012-12-11 16:42 ` Yufeng Zhang
2012-11-16 20:04 ` Tom Tromey
2012-11-12 21:26 ` Doug Evans
2012-11-13 17:43 ` Tom Tromey
2012-11-13 15:44 ` Jan Kratochvil
2012-11-13 18:34 ` Tom Tromey
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=20121114221211.GA3790@adacore.com \
--to=brobecker@adacore.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=tromey@redhat.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