Hi,
I was reading the "Problem reading corefiles on ARM" thread at the gcc
mailing list (from www-archive, I'm not subscribed) and the conclusions
are incorrect:
http://gcc.gnu.org/ml/gcc/2008-08/msg00075.html
The problem in GCC noreturn attribute handling isn't how
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> ...OK, consider this case:
Joe> int func1(int); void func2(int); bool test(void); void
Joe> func3(int);
Joe> void func(int arg) { int v1 = func1(arg); func2(v1); if (test())
Joe> { func3(v1); } }
Joe> Here if we put v1 in a register
Joe> After all, if we have
int func1(int);
void func2(int);
void ordinary_function(void);
void func(int arg) {
int v1 = func1(arg);
func2(v1);
ordinary_function();
}
> Joe> and there's a segfault in ordinary_function, in general v1 isn't
> Joe> going to be kept around for i
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Paul Koning <[EMAIL PROTECTED]> writes:
>> > That's sufficient for live debugging but not for corefiles. In
>> that > case you do want caller-saved registers, because they may
>> contain > local variable values that don't live in memory
> From: mark@
> To: drow@; gcc@
> CC: sposelenov@; gdb@
> I suppose it optimizes away the instructions to save the return
> address, because abort() is marked with __attribute__(noreturn). But
Ouch. Other compilers put a breakpoint after a call to any noreturn function.
Really, the com
Paul Koning <[EMAIL PROTECTED]> writes:
> > That's sufficient for live debugging but not for corefiles. In that
> > case you do want caller-saved registers, because they may contain
> > local variable values that don't live in memory at the time of the
> > abort call.
On Wed, Aug 06, 2008 at 11:
Paul Koning <[EMAIL PROTECTED]> writes:
> That's sufficient for live debugging but not for corefiles. In that
> case you do want caller-saved registers, because they may contain
> local variable values that don't live in memory at the time of the
> abort call.
In an optimized build you can't exp
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> I wrote: There are several effects from "noreturn". We would
Joe> want some of these effects for "abort", but not others, to get
Joe> debuggable code without degrading compile-time warnings.
Joe> On Wed, Aug 06, 2008 at 01:37:51PM -040
I wrote:
> Joe> There are several effects from "noreturn". We would want some
> Joe> of these effects for "abort", but not others, to get debuggable
> Joe> code without degrading compile-time warnings.
On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote:
> So the issue is that two unr
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
>> I think the space savings in "noreturn" come from not having to
>> save caller-saved registers in the calling function. That savings
>> can add up if the noreturn function
On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
> I think the space savings in "noreturn" come from not having to save
> caller-saved registers in the calling function. That savings can add
> up if the noreturn function is called from many places.
>
> Clearly the return address needs
> "Mark" == Mark Kettenis <[EMAIL PROTECTED]> writes:
>> Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz
>> <[EMAIL PROTECTED]>
>>
>> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
>> > (gdb) bt > #0 0x4004ec0c in raise () from /lib/libc.so.6 > #1
>> 0x40
On Wed, Aug 06, 2008 at 05:42:48PM +0200, Mark Kettenis wrote:
> GCC should really not do this. People are almost guaranteed to want
> to be able to see a backtrace from abort(3).
Yes, it's come up for discussion several times... I don't like the
current behavior either. The current behavior was
> Date: Wed, 6 Aug 2008 11:27:36 -0400
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
> > (gdb) bt
> > #0 0x4004ec0c in raise () from /lib/libc.so.6
> > #1 0x40050234 in abort () from /lib/libc.so.6
> > Backtrace stopped: frame
14 matches
Mail list logo
