[llvm-commits] Uninitialized EH DWARF in the JIT

[Nick Lewycky]

Reid Kleckner wrote:
> I think I'm not hitting that code because we don't catch any
> exceptions or have any stack-allocated values with destructors, so it
> just returns early.
> 
> It seems that the first alignment does its own initialization, and the
> second one doesn't seem used.  I think it's beyond the end of the
> exception table, but I guess it's good to be safe.  I changed both to
> fill with zeros.
> 
> Here's an updated patch.

This makes emitAlignment dead then, right? Why not change emitAlignment 
to write the nops, and not take an extra parameter?

Also, don't reimplement RoundUpToAlignment() as AlignPtr().

Nick

> On Thu, Aug 20, 2009 at 9:21 PM, Nick Lewycky<nicholas at mxc.ca> wrote:
>> Reid Kleckner wrote:
>>> Hello,
>>>
>>> This patch fixes a bug where the DWARF emitter in the JIT was not
>>> initializing alignment bytes.  libgcc doesn't seem to mind, but if you
>>> pass this EH info to GDB, it doesn't like it.  I don't think that in
>>> general the JIT should initialize the alignment bytes, since they
>>> aren't used, so I added a method emitAlignmentWithFill that does it.
>>>
>>> Also, note that if you try to adjust the length to not include the
>>> uninitialized bytes, readelf -wf *really* doesn't like it, so I went
>>> with this solution instead.
>> You only changed 2 of 4 occurrences of emitAlignment to
>> emitAlignmentWithFill. Why aren't the other two causing you problems?
>>
>>> Please review; I can commit the patch myself.
>> +private:
>> +  /// AlignPtr - Align Ptr to Alignment bytes, rounding up.  Alignment
>> should
>> +  /// be a power of two.  This method rounds up, so AlignPtr(7, 4) == 8 and
>> +  /// AlignPtr(8, 4) == 8.
>> +  static uint8_t *AlignPtr(uint8_t *Ptr, size_t Alignment) {
>>
>> Please use RoundUpToAlignment() from llvm/Support/MathExtras.h.
>>
>> Nick
>>
>>