public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Steven Johnson <sjohnson@sakuraindustries.com>
To: Jonathan Larmour <jifl@eCosCentric.com>
Cc: Daniel Jacobowitz <drow@false.org>,  gdb@sources.redhat.com
Subject: Re: Thread backtrace termination
Date: Wed, 13 Jul 2005 10:35:00 -0000	[thread overview]
Message-ID: <42D62354.5090607@sakuraindustries.com> (raw)
In-Reply-To: <42D40C9D.7070204@eCosCentric.com>

Jonathan Larmour wrote:

> Daniel Jacobowitz wrote:
>
>> On Mon, Jul 11, 2005 at 06:52:13PM +0100, Jonathan Larmour wrote:
>>
>>> Daniel Jacobowitz wrote:
>>
[snip]

>>> Alternatively, how about adding a new command that allows you to 
>>> define a set of entry point symbol names? People can then put an 
>>> appropriate list for themselves or their OS in ~/.gdbinit. Or it can 
>>> be pre-initialised by the OS support within GDB if there is one. 
>>> e.g. nm-linux.h. Here's what I'm thinking of:
>>>
>>> set entry-point-name-list main _start _entry
>>>
>>> Although handling mangled symbols and multiple languages might be 
>>> fun. I'm not an expert on such things.
>>
>>
>>
>> *shrug* maybe.
>
>
> Well, I'm prepared to create a patch to add such a command if people 
> here think something with that principle would be accepted.

Instead of a "set" command, which sets an entire list, an "add" and 
"delete" command that adds to the list and deletes from the list 
respectively would be (in my opinion) more useful, because GDB could 
default to the standard entries for a target, and then extra's could be 
added to/removed from the list.

set entry-point-list add [name]
set entry-point-list delete [name]

(for example)

Alternatively there could be 2 lists, one full of default which you 
usually dont change, and one with user added entries.

set entry-point-name-list-default [list]
set entry-point-name-list-user [list]

By default user would be empty, and would be only set by the user (in a 
script or otherwise).  So the user could be assured they werent messing 
with any defaults they didnt want to change.

or the like.

supporting wildcards might also be useful, such as:

set entry-point-list add thread_*

or

set entry-point-list delete *

so if a programmer had a convention of calling all their threads 
"thread_blah" they wouldnt have to explicitly name them all, back trace 
would terminate at any function with that naming convention. 

Just some suggestions, if you are going to do this.  My opinion is such 
a feature would be worthwhile.  If the information can not be easily 
provided (or at all) from debug symbols, it would seem highly desirable 
to have a manual method of inserting the information.

Steven

  reply	other threads:[~2005-07-13 10:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 16:21 Jonathan Larmour
2005-07-11 16:23 ` Daniel Jacobowitz
2005-07-11 17:52   ` Jonathan Larmour
2005-07-11 18:19     ` Daniel Jacobowitz
2005-07-12 18:32       ` Jonathan Larmour
2005-07-13 10:35         ` Steven Johnson [this message]
2005-07-13 12:53           ` GDB is stepping past main() Konstantin Karganov
2005-07-13 13:05             ` Daniel Jacobowitz
2005-07-13 13:31               ` Konstantin Karganov
2005-07-13 13:39                 ` Nathan J. Williams
2005-07-13 13:47                   ` Konstantin Karganov
2005-07-13 13:50                     ` Dave Korn
2005-07-13 13:46                 ` Daniel Jacobowitz
2005-07-13 13:57                   ` Konstantin Karganov
2005-07-14 14:27                   ` MI *stopped reason Konstantin Karganov
2005-07-14 14:40                     ` Bob Rossi
2005-07-14 15:15                     ` Incorrect breakpoint diagnostics in MI Konstantin Karganov

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=42D62354.5090607@sakuraindustries.com \
    --to=sjohnson@sakuraindustries.com \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=jifl@eCosCentric.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).