Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Danny Backx <danny.backx@scarlet.be>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: shared lib dos filename style - one more question
Date: Thu, 08 Oct 2009 16:01:00 -0000	[thread overview]
Message-ID: <1255017831.10921.197.camel@pavilion> (raw)
In-Reply-To: <20091007201145.GA21557@caradoc.them.org>

On Wed, 2009-10-07 at 16:11 -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 07, 2009 at 10:07:55PM +0200, Danny Backx wrote:
> > No reply to the message below. I'm including my current work now. Please
> > comment.
> 
> I've been staying out of this conversation because I don't have time
> to discuss it properly, but I am still skeptical that this should ever
> be a user setting - I've yet to see a plausible problem if we always
> handled both styles of filesystem.
> 
> If it does need to be a user setting, IMO it's acceptable to make
> users set it in their .gdbinit or on the GDB command line.

I'm sure that any effects of discouragement at my end are not the
intention of this message :-)

I'm perfectly willing to continue work on this (makes no sense to drop
it now), but I'd like to know where to go from here.

I'll ask some questions, maybe this'll give clarity :
1. If this work (or the way it's currently implemented) is questionable,
   then why have an effect on libiberty ?
   So : do we want this to go as far as extending libiberty slightly ?
2. This may all be much too complicated. Stuff the solution, make sure
   that forward slashes as well as backslashes as well as C:/ stuff
   are always supported.
   A very good or a very bad idea ?
   It would conflict with the "let's take this one step at a time" that
   someone told me.
3. Great idea. We'll get more of this soon. But let's not go further
   right now. Implement it as is, don't go the extra mile to re-
   evaluate everything if the user changes the variable in the middle
   of a session.
   What's good or bad about this ?
4. gdbserver is a bad idea. gdb shouldn't bother with debugging
   architectures that look different from the development host.
   I'm not sure what the question is here.

These may be bad questions but it feels like the right time to stir up
the discussion.

	Danny

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


  reply	other threads:[~2009-10-08 16:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-26 13:49 Danny Backx
2009-10-07 20:05 ` Danny Backx
2009-10-07 20:11   ` Daniel Jacobowitz
2009-10-08 16:01     ` Danny Backx [this message]
2009-10-09 17:36       ` Joel Brobecker
2009-10-09 18:58         ` Danny Backx
2009-10-10  2:19           ` Joel Brobecker
2009-10-12 20:05             ` Danny Backx
2009-10-12 20:28               ` Eli Zaretskii
2009-10-13  5:24                 ` Joel Brobecker
2009-10-13 10:57                   ` Pedro Alves
2009-10-13 15:30                     ` Joel Brobecker
2009-10-13 18:23                       ` Eli Zaretskii
2009-10-13 18:12                   ` Eli Zaretskii
2009-10-13 18:19                     ` Daniel Jacobowitz
2009-10-12 20:45             ` Daniel Jacobowitz
2009-10-13  5:21               ` Joel Brobecker
2009-10-13 15:51                 ` Daniel Jacobowitz
2009-10-14 20:18               ` Danny Backx
2009-10-17  4:16                 ` Joel Brobecker

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=1255017831.10921.197.camel@pavilion \
    --to=danny.backx@scarlet.be \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    /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