From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans-Bernhard Broeker To: gdb@sourceware.cygnus.com Cc: Eli Zaretskii Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00510.html This is an answer to < 20000301123337B.mitchell@codesourcery.com > [I've been pointed to this discussion by Eli Zaretskii, but I'm not on the gdb mailing list, myself. I just read through it on the WWW archive. So please, if you answer, Cc: to me, if possible. Thank you.] The point raised in this discussion has, by coincidence, caused a similar problem, with the DJGPP release version of GCC 2.95.2 and GDB 4.18. The problem is that for very short functions (one, maybe two lines of actual code, between the braces), gdb would not stop *at all* if you 'step' into a function from outside, because of badly positioned line number debug symbols. Looking at the assembly generated by GCC, it turned out that the problem lies in the way the function prologues and epilogues were written, compared to earlier GCC releases. So, to answer one of the questions raised in your discussion: to some extent, the prologue/epilogue have indeed changed, since 1994. The whole method of outputting prologues has been changed, since gcc-2.8.1, it seems, even though the typical set of machine operations has stayed the same, for this platform. Originally, prologues and epilogues were generated directly as assembly, by a specialized function, i.e. they were not subject to RTL transformations. Now, by default at least, they're generated as RTL, rather early in the compilation, and subject to modification along with the 'real code'. As to the question where the first line number label ought to be put, and what line it should point, I think the behaviour of previous GCC/GDB combinations was perfectly sane: the line number opcode is output right after the prologue, and it points to the line the next machine instruction originated from (initialization of an automatic variable, if present, an executable statement otherwise). Opposed to this expected behaviour, gcc-2.95.2 outputs a line note *before* the prologue (and one for the closing brace after the epilogue, instead of before it, as it used to be). By disabling the RTL-style prologue generating mechanism (undocumented GCC option -mno-schedule-prologue), you get back the traditional behaviour. Currently, the conclusion of discussion between me and Eli is that this constitutes a bug in gcc-2.95.2. Wether or not that's still present in the current snapshot remains to be checked. AFAICS, the GCC patch from Mark Mitchell that caused all this hassle for your GDB testsuite meant to fix that, but didn't work out as planned. Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.