On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
> Since the cvs version of gas supports extensions for the dwarf2
> basic_block location information, I thought I could try to add support
> to gcc for this feature.
I had been working on this, but got distracted. I hope to get
bac
On Tue, Nov 15, 2005 at 12:26:37PM +0100, Mathieu Lacage wrote:
> Out of curiosity, I wonder what gdb would use it for.
I don't have any concrete plans. But among the things a debugger can
do with this information:
- Display likely jump targets to the user.
- Set breakpoints on every basic blo
Mathieu Lacage wrote:
svn diff -x -p does not work here. Is there a magic incantation I should
run to produce such a diff ?
There are some instructions in the gcc wiki about how to do this. The
gcc wiki is accessible from our home page, gcc.gnu.org. svn uses a
built-in diff that doesn't sup
On Tue, Nov 15, 2005 at 08:19:06AM +0100, Mathieu Lacage wrote:
> It would be nice if you could post an example where they are not
> combined.
I don't have any example, but the compiler is not under obligation to
do this, as far as I know. Or it may change in the future. This is
very much an int
Here is an updated version with a few bugs fixed (How I managed to
introduce bugs in a 20-liner patch still eludes me).
On Mon, 2005-11-14 at 21:26 -0500, Daniel Jacobowitz wrote:
> On Mon, Nov 14, 2005 at 06:24:47PM -0800, Jim Wilson wrote:
> > mathieu lacage wrote:
> > >Clearly, 0x11 is not a b
On Mon, 2005-11-14 at 21:30 -0500, Daniel Jacobowitz wrote:
> On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
> > While the debugging output looks quite correct at -O0, the -O2 output
> > seems broken:
> > :
> > 0: 8d 4c 24 04 lea0x4(%esp),%ecx
> > 4:
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
> While the debugging output looks quite correct at -O0, the -O2 output
> seems broken:
> :
> 0: 8d 4c 24 04 lea0x4(%esp),%ecx
> 4: 83 e4 f0and$0xfff0,%esp
> 7: ff 71 fc
On Mon, Nov 14, 2005 at 06:24:47PM -0800, Jim Wilson wrote:
> mathieu lacage wrote:
> >Clearly, 0x11 is not a bb boundary so we have a bug.
>
> Looks like it could be the prologue end, but I don't see any obvious
> reason why this patch could do that. I suggest you try debugging your
> patch t
mathieu lacage wrote:
Clearly, 0x11 is not a bb boundary so we have a bug.
Looks like it could be the prologue end, but I don't see any obvious
reason why this patch could do that. I suggest you try debugging your
patch to see why you are getting the extra call with
LINE_FLAG_BASIC_BLOCK se
