Mail Archives: djgpp-workers/2000/03/01/19:16:18
On Wed, 1 Mar 2000, salvador wrote:
> > Or followed changes to register contents? When a C instruction is
> > broken into several parts by the optimizer's instruction reordering phase,
> > intermediate results will be in registers, rather than in the actual
> > variables. I.e. gdb may not see them, at all.
>
> That's not 100% correct, gdb can see values in registers, the problem is when gcc
> moves the value from one register to another. It looks like this can't be modeled
> with these debug information.
> Is true that some of the back and forth is due to reordering and also because one
> single line is split it more than one assembler chunck, but looks like the exact
> line isn't recorded very well so you jump to places that aren't the exact place,
> like jumping to the opening { of a function when in fact it should be to one line
> above (initialization of the parent class) or other place.
> So perhaps the problem is that 2.95 moves too much things and when trying to
> record it some things gets wrong.
It strikes me that these problems should be brought before GCC
maintainers (possibly with a CC: to gdb AT sourceware DOT cygnus DOT com), so that
we at least could have the official say-so of the GCC development team.
Since changing the optimization switches to debug code is IMHO a Bad Idea
(tm), I think it's very important to make sure any bugs associated with
generating debug info are identified and fixed.
Don't be alarmed by the size of your sources/preprocessed files that you
need to show to illustrate the problem: just put it on some Web page and
post the URL with your report.
- Raw text -