Bug 118895 - Allow setting of additonal gdb-specific options
Summary: Allow setting of additonal gdb-specific options
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug (show other bugs)
Version: 3.0.1   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: cdt-debug-inbox@eclipse.org CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
: 82019 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-01 13:36 EST by Joanne Woo CLA
Modified: 2020-09-04 15:17 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joanne Woo CLA 2005-12-01 13:36:28 EST 
Allow setting of additonal gdb-specific options in debug launch configuration  such as:

backtrace limit
follow-fork-mode
Comment 1 Nobody - feel free to take it CLA 2005-12-01 14:25:03 EST 
*** Bug 82019 has been marked as a duplicate of this bug. ***
Comment 2 Nobody - feel free to take it CLA 2005-12-01 15:26:24 EST 
A property page is needed to change these options during debugging.
Comment 3 Joanne Woo CLA 2005-12-01 18:29:50 EST 
Mikhail, I've implemented setting folow-fork-mode in the debug launch config and it's working fine.  I'm currently hardcoding backtrace limit but I don't see why that can't also be set in the debug launch config, which is what I'm planning to do.
Comment 4 Joanne Woo CLA 2005-12-01 22:28:28 EST 
On second thought, I agree that these settings should go into the a preference page so that the settings apply to all projects rather than the per-project debug launch config.
Comment 5 Nobody - feel free to take it CLA 2005-12-01 23:58:28 EST 
I am not saying that it shouldn't be in the launch configuration. The standard approach is preferences -> launch configurations -> properties.
Preferences provide the default values, launch configurations set the initial values for the session and properties are used to cahnge the values during the session.
BTW, why do you need to set backtrace limit. The number of requested stack frames is limited internally. And the backtrace limit affect some operations.
Comment 6 Johan Walles CLA 2005-12-02 02:23:33 EST 
If you generate code dynamically gdb sometimes gets lost and gives you infinite backtraces.  That would be one reason you might want to limit backtraces.
Comment 7 Nobody - feel free to take it CLA 2005-12-02 10:34:15 EST 
The problem with backtrace limit is if it's too small the "stack-info-depth" command returns error for valid number of frames.
Comment 8 Joanne Woo CLA 2005-12-02 12:35:03 EST 
In my case, I used backtrace limit to work around a bug in gdb and kgdb where where I was getting an infinite backtrace while debugging a kernel and DevRocket was hosed as a result.

Even with a backtrace limit of 100 (a value suggested by Daniel Jacobowitz), DevRocket took a significantly long time to refresh and seemed to be hung for awhile.  That was with CDT 2.1.x.  I've not tried this with CDT 3.0.x.

If backtrace limit is to be implemented as an option in CDT, the allowed values must be within a range that is neither too small nor too large.
Comment 9 Mike Whittaker CLA 2008-03-13 07:57:25 EDT 
I would also like to be able to customise /any/ of the gdb settings currently
preset by Eclipse - surely sensible design in any case ?

I am currently locked by circumstances into using an older version of gdb,
that complains about option '-i'. If I could get at this canned setting
it would make life much easier.

>>>
Error creating session
/usr/bin/gdb: unrecognized option `-i'
<<<