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
next prev parent 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).