* Option to disable frame checking
@ 2012-10-01 17:04 Joshua Watt
2012-10-01 17:21 ` Joel Brobecker
0 siblings, 1 reply; 6+ messages in thread
From: Joshua Watt @ 2012-10-01 17:04 UTC (permalink / raw)
To: gdb
I'm using GDB on a ARM architecture with a custom OS
(--target=arm-eabi). In certain cases, we call functions on a
completely separate stack from the one that the thread normally uses.
In these cases, GDB fails to do a backtrace through the function call
with an UNWIND_INNER_ID error, even though all the correct stack
unwinding debug information is present. Is it acceptable to make a
patch that allows this check to be turned off (i.e. "set
frame-inner-check off" or similar), or is there another method that is
more acceptable?
--
Joshua Watt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Option to disable frame checking
2012-10-01 17:04 Option to disable frame checking Joshua Watt
@ 2012-10-01 17:21 ` Joel Brobecker
2012-10-01 17:26 ` Jan Kratochvil
0 siblings, 1 reply; 6+ messages in thread
From: Joel Brobecker @ 2012-10-01 17:21 UTC (permalink / raw)
To: Joshua Watt; +Cc: gdb
> Is it acceptable to make a patch that allows this check to be turned
> off (i.e. "set frame-inner-check off" or similar), or is there another
> method that is more acceptable?
Knowing that the Go language makes extensive use of alternate stacks,
I think it's just better to remove the check altogether.
--
Joel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Option to disable frame checking
2012-10-01 17:21 ` Joel Brobecker
@ 2012-10-01 17:26 ` Jan Kratochvil
2012-10-01 17:59 ` Joel Brobecker
2012-10-01 18:39 ` Joshua Watt
0 siblings, 2 replies; 6+ messages in thread
From: Jan Kratochvil @ 2012-10-01 17:26 UTC (permalink / raw)
To: Joel Brobecker; +Cc: Joshua Watt, gdb
On Mon, 01 Oct 2012 19:21:17 +0200, Joel Brobecker wrote:
> > Is it acceptable to make a patch that allows this check to be turned
> > off (i.e. "set frame-inner-check off" or similar), or is there another
> > method that is more acceptable?
>
> Knowing that the Go language makes extensive use of alternate stacks,
> I think it's just better to remove the check altogether.
I do not know about Go alternate stacks but the checks for example already
supports gcc -fsplit-stack. More such features should be rather implemented
than to drop UNWIND_INNER_ID. Could not be GDB taught about thue alternate
stack?
Looping backtraces are a pain for both interactive and automatic bugreporting,
it is already a TODO item GDB should better handle f() { f(); } type stack
overflows as it proven less GDB-savvy users fail to debug such issue in GDB.
Thanks,
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Option to disable frame checking
2012-10-01 17:26 ` Jan Kratochvil
@ 2012-10-01 17:59 ` Joel Brobecker
2012-10-01 18:39 ` Joshua Watt
1 sibling, 0 replies; 6+ messages in thread
From: Joel Brobecker @ 2012-10-01 17:59 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Joshua Watt, gdb
> I do not know about Go alternate stacks but the checks for example
> already supports gcc -fsplit-stack.
I think we're both talking about the same feature - I couldn't remember
the exact technical term used for Go.
> More such features should be rather implemented than to drop
> UNWIND_INNER_ID. Could not be GDB taught about thue alternate stack?
>
> Looping backtraces are a pain for both interactive and automatic
> bugreporting, it is already a TODO item GDB should better handle f() {
> f(); } type stack overflows as it proven less GDB-savvy users fail to
> debug such issue in GDB.
Personally, I don't think tha the check and associated warning brings
anything extra. Getting a cryptic warning about some frame being inner
than another never really helped me more than getting a botched backtrace.
On the other hand, determining that a frame fails that invariant should
be relatively straightforward, thanks to the "info frame" command. Hence
the suggest to toss the check.
But if people prefer to keep the check, and have a technical way of
handling this sort of issue, then why not.
--
Joel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Option to disable frame checking
2012-10-01 17:26 ` Jan Kratochvil
2012-10-01 17:59 ` Joel Brobecker
@ 2012-10-01 18:39 ` Joshua Watt
2012-10-01 18:54 ` Jan Kratochvil
1 sibling, 1 reply; 6+ messages in thread
From: Joshua Watt @ 2012-10-01 18:39 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Joel Brobecker, gdb
>> > Is it acceptable to make a patch that allows this check to be turned
>> > off (i.e. "set frame-inner-check off" or similar), or is there another
>> > method that is more acceptable?
>>
>> Knowing that the Go language makes extensive use of alternate stacks,
>> I think it's just better to remove the check altogether.
>
> I do not know about Go alternate stacks but the checks for example already
> supports gcc -fsplit-stack. More such features should be rather implemented
> than to drop UNWIND_INNER_ID. Could not be GDB taught about thue alternate
> stack?
I'm not sure how that would be accomplished. AFAIK, there isn't any sort of
information in the DWARF debugging format that could be used to (definitively)
indicate the thread has jumped stacks, so I think it would have to be determined
by something external to the code being debugged. I think that such a heuristic
approach could be difficult to get correct in all cases, hence the
idea of making it
a user configurable option.
I won't claim to be an expert in the DWARF debugging format though, so
I could be
wrong. I also don't know anything about any other debugging formats.
--
Joshua Watt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Option to disable frame checking
2012-10-01 18:39 ` Joshua Watt
@ 2012-10-01 18:54 ` Jan Kratochvil
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kratochvil @ 2012-10-01 18:54 UTC (permalink / raw)
To: Joshua Watt; +Cc: Joel Brobecker, gdb
On Mon, 01 Oct 2012 20:38:54 +0200, Joshua Watt wrote:
> I'm not sure how that would be accomplished. AFAIK, there isn't any sort of
> information in the DWARF debugging format that could be used to (definitively)
> indicate the thread has jumped stacks, so I think it would have to be determined
> by something external to the code being debugged. I think that such a heuristic
> approach could be difficult to get correct in all cases,
In such case the "alternate stack" feature is insufficiently designed and it
should be extended for its debuggability. Debuggability is a normal
associated part of any new ABI feature.
> hence the idea of making it a user configurable option.
Every user configurable option is just a last resort workaround. In the best
world there would be no configuration options, ever.
> I won't claim to be an expert in the DWARF debugging format though,
It does not always have to be in DWARF. For example the gcc -fsplit-stack did
not need any DWARF extensions (it was enough to verify specific ELF symbol).
http://sourceware.org/git/?p=gdb.git;a=commitdiff;h=457da755a718113dcbc339f7823af0d439fa62c7
Thanks,
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-01 18:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-01 17:04 Option to disable frame checking Joshua Watt
2012-10-01 17:21 ` Joel Brobecker
2012-10-01 17:26 ` Jan Kratochvil
2012-10-01 17:59 ` Joel Brobecker
2012-10-01 18:39 ` Joshua Watt
2012-10-01 18:54 ` Jan Kratochvil
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).