Mathieu Lacage - Re: dwarf2 basic block start information (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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: 00000000

: 0: 8d 4c 24 04 lea 0x4(%esp),%ecx 4: 83 e4 f0 and $0xfffffff0,%esp 7: ff 71 fc pushl 0xfffffffc(%ecx) a: 55 push %ebp b: 89 e5 mov %esp,%ebp d: 53 push %ebx e: 31 db xor %ebx,%ebx 10: 51 push %ecx 11: 83 ec 10 sub $0x10,%esp 14: 8d b6 00 00 00 00 lea 0x0(%esi),%esi

With this list of basic block boundaries as reported by the debugging information: ad: 0x0 ad: 0x11

Clearly, 0x11 is not a bb boundary so we have a bug. Despite the fact

This was a bug in my dwarf2 reading code. I fixed it and this testcase works for me now.

No, not clear at all. Every place which could be the target of a jump will be the start of a basic block, but you are not guaranteed that all sequential basic blocks are combined. Probably either Jim's right and

It would be nice if you could post an example where they are not combined.

it's related to the end of the prologue, or it's a different basic block because of some artifact of inlining. This shouldn't present any problem for a tool using the basic block information.

Inlining or end-of-prologue do not seem to have an influence on this. It seems to actually work quite well. I will send an updated version of the patch in another email.

Mathieu

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]