This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp
- From: Christophe LYON <christophe dot lyon at st dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 17 Apr 2009 19:06:09 +0200
- Subject: Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp
- References: <49CCDB3D.5010302@st.com> <20090327184726.GW9472@adacore.com> <49D083FB.6020108@st.com> <20090330170216.GB9472@adacore.com> <49D21E7E.8080708@st.com> <20090401183240.GD8766@adacore.com> <49D47C75.9000206@st.com>
I'm OK with leaving the testcase untouched if we don't need to.
OK. So I won't commit my patch, and fix the compiler instead.
I have been trying to fix the compiler so that it behaves like GCC
(using 2 separate filenames for the actual source file and for the one
provided with #line), but I get regressions later in step-line.exp.
After dumping the debug_line info (with readelf and/or dwarfdump), I
mostly noticed that the file number has changed according to the
compiler fix.
However, from GDB, using "maintenance print symbols", I noticed that
quite a few lines have become "0" instead of meaningful values. In turn,
I thinks this makes skip_prologue do something wrong.
What I dont' understand currently is where those "0" line entries come
from? Is there any verbose flag or maintenance command I could use to
understand how the Dwarf debug_line info is parsed?
Thanks,
Christophe.