Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <tech-userlevel@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/20/2005 03:28:33
>> Abstractly, the same thing is true of inlining bcopy [...] [T]he
>> major difference is that a frame is missing from the call stack,
> Hm, no frame on the call stack =?
When you fire up a debugger, instead of seeing a call stack like
main -> foo -> bar -> bcopy -> *boom*
you see just
main -> foo -> bar -> *boom*
and when you look at the code at the pc, it turns out it's "inside" the
"call" to bcopy. A little confusing to someone who hasn't seen it
before, or who doesn't realize the compiler does that kind of inlining.
> This seems wrong, at first glance,
Yeah. It's another way in which the compiler making transformations
that are semantically equivalent when their semantics are defined by
the spec can lead to trouble when the circumstances are such that the
semantics aren't defined by the spec.
> but nothing that -ffreestanding wouldn't solve, I guess.
Yeah...except that that "solves" a lot more than this. (The real
problem, of course, is not just this one instance, but more generally
the gcc maintainers assuming that semantics undefined by the standard
have not been defined by any gcc target - like what our printf does, or
at least used to do, with nil pointers, printing them as (null).)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B