Gabriel Dos Reis writes: > On Wed, 17 Jan 2007, Andrew Haley wrote: > > | Gabriel Dos Reis writes: > | > On Wed, 17 Jan 2007, Andrew Haley wrote: > | > > | > [...] > | > > | > | > | "To a man with a hammer, all things look like a nail." It's very > | > | > | tempting for us in gcc-land always to fix things in gcc, not > because > | > | > | it's technically the right place but because it's what we control > | > | > | ourselves. > | > | > > | > | > well, I'm unclear what your point is here, but certainly GCC is > | > | > at fault for generating trapping instructions. > | > | > So, we fix the problem in GCC, not because that is what we control > | > | > ourselves, but we we failed to generate proper code. > | > | > | > | It's not a matter of whose fault it is; trying to apportion blame > | > | makes no sense. > | > > | > we have a communication problem here. Nobody is trying to apportion > | > blame. However, gcc is the tool that generates trapping instruction. > | > It is unclear why it would be the responsability of the OS or libc > | > to fix what GCC has generated in the first place. > | > | That makes no sense either. > | > | It's an engineering problem. We have a widget that does the wrong > | thing*. We have several ways to make it do the right thing, only one > | of which has no adverse impact on the existing users of the widget. > > You believe there is one solution, except that it does not work for > the supported target.
Sorry, I don't understand what you mean by that. I've been thinking about why we see this so very differently, and it's dawned on me why that is. I first came across this "architectural feature" of the 8086 in the mid-1980s. To begin with, there was no divide overflow handler at all: the machine would simply crash. It took me a little while to figure out what was happening, but once I'd done so it was a simple matter to write a few lines of assembly language that fix up the operands and carry on. Fast-forward ten years or so and for the first time I come across unices running on an x86. And I was surprised to see that rather than fixing up the operands and continuing, the kernel punted the problem to the user's program, which usually responded by core dumping. "OK," I thought, "that must be what UNIX programmers want. This trap must be desired, because it is trivially easy to fixup and continue. Perhaps it's because programmers want to be alerted that there is a bug in their program." And that's what I thought until last week. :-) Andrew.
