[llvm-commits] Uninitialized EH DWARF in the JIT

[Reid Kleckner]

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.

Reid

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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jit-eh-patch.diff
Type: text/x-patch
Size: 5423 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090821/5202e9cb/attachment.bin>