[lld] r218703 - [mach-o] create __unwind_info section on x86_64

Rui Ueyama ruiu at google.com
Fri Oct 17 16:47:28 PDT 2014


On Fri, Oct 17, 2014 at 3:59 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> Hi Rui,
>
> <sniiiiiiiiiiiiiiiip>
> >> +  void addCommonEncodings(std::vector<uint32_t> &commonEncodings) {
> >> +    using normalized::write32;
> >> +
> >> +    _contents.resize(_commonEncodingsOffset +
> >> +                     commonEncodings.size() * sizeof(uint32_t));
> >> +    int32_t *commonEncodingsArea =
> >> +        (int32_t *)&_contents[_commonEncodingsOffset];
> >
> >
> > It doesn't seem to be guaranteed that _commonEncodingsOffset is a valid
> > index. If I add
> >
> >   assert(_commonEncodingsOffset < _contents.size());
> >
> > many tests start failing.
>
> I'd actually expect _commonEncodingsOffset == _contents.size() in all
> cases (and an assert seems to confirm this). We've added the top-level
> header, the next bytes (which we' rather like to be contiguous for
> efficiency reasons) are the common encodings, so we resize the buffer
> to give them room.


commonEncodings.size() can be zero it seems. In that case _contents become
the same size as _commonEncodingsOffset.

I don't think taking an address of v[n] where n is an integer and v is a
std::vector of size n is valid. If you run this test on Windows with debug
build, it will actually fail because of an assertion in the standard
library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141017/41006595/attachment.html>


More information about the llvm-commits mailing list