[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