Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFC/WIP] unit test for separate debug info
Date: Wed, 12 Nov 2003 14:44:00 -0000	[thread overview]
Message-ID: <16306.18251.628820.803325@localhost.redhat.com> (raw)
In-Reply-To: <20031111211924.9D4F94B361@berman.michael-chastain.com>

Michael Elizabeth Chastain writes:
 > Hi Elena,
 > 
 > Ah, I was mixing two things together.  I definitely prefer the doco
 > in the format above.  That's one thing.  I was also adding in my own
 > preferences for the file names.  That's a different thing.
 > 

I agree with you about the comment needing to be more explicit.

 > I like gdb.base/break.sym or gdb.base/break.debug a lot more than
 > gdb.base/.debug/break.debug.  That keeps all the files parallel
 > instead of some files inside a dot directory.
 > 

Can't do this one. This is the way that gdb is doing the search, the
default configuration is such that it looks into the .debug
subdirectory.  However, you bring up another valid point, which is
that there is a command in gdb that allows you to change the default
location of the debug files. And I forgot to add that to the test.  I
think I'll do the default location, then move/copy the .debug file and
test the gdb command that changes the location. 

 > 
 > I see your point.  And I see that you see my point.  :)  I guess
 > I'm on your side now.  It's important to test what people actually do.
 > Although if I were building these things as end user of gcc/binutils/gdb,
 > I would build:
 > 
 >   break.full		# full debugging info
 >   break.stripped	# stripped executable
 >   break.sym		# symbols
 >   break.ship		# break.full - symbols + link to break.sym
 >   break			# copy of break.ship
 > 

yes, true. But the distros are coming out with the weird name scheme.
In reality it doesn't make much of a difference. I can change the name
of the final executable in the testcase, and I tried that, no difference.

 > Oh, yeah, I also like the MS-DOS convention of 'break.exe'
 > and I would like to change Unix to do that also.  So I have
 > weird taste.
 > 

er....

elena


  parent reply	other threads:[~2003-11-12 14:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-11 21:19 Michael Elizabeth Chastain
2003-11-11 21:22 ` Daniel Jacobowitz
2003-11-12 14:44 ` Elena Zannoni [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-11-08  1:28 Michael Elizabeth Chastain
2003-11-11 16:26 ` Elena Zannoni
2003-11-07 20:21 Michael Elizabeth Chastain
2003-11-07 20:03 Elena Zannoni
2003-11-07 20:39 ` Kevin Buettner

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=16306.18251.628820.803325@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec.gnu@mindspring.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