* Ben Hutchings <b...@decadent.org.uk> [121028 17:02]:
> There are plenty of bugs that involve 'undefined behaviour' that in
> practice depends on whether optimisation is enabled. Unless you have a
> good idea what's going wrong, how do you know that 'noopt' won't hide
> the bug?
If the bug still shows up with the library recompiled with 'noopt', then
no harm done. If it is a bug in the library, you want to look there
anyway (and you will most likely want to compile different parts of it
with or without optimisation or any other technique; in any case you
will want more of the library than just the binary and some debugging
symbols of it). The only case where a noopt library variant is a
disadvantage is a very ugly case of heisenbug, that is hidden by the
slightly changed library.
> Also, gdb and the GNU toolchain have recently got a lot better
> at handling highly optimised code (tracking variables in registers,
> treating inlined functions as logically separate functions, etc.).
Yeah, they got a lot better. But even if gdb got perfect in that regard
it can still not show what isn't there (like the value of a variable
(or function argument passed as register) no longer stored anywhere.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028163707.ga19...@client.brlink.eu
