<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Patch up for review: <a href="https://reviews.llvm.org/D47646" class="">https://reviews.llvm.org/D47646</a><div class=""><br class=""></div><div class="">thanks,</div><div class="">vedant<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 1, 2018, at 11:31 AM, Vedant Kumar <<a href="mailto:vsk@apple.com" class="">vsk@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 1, 2018, at 1:39 AM, Pavel Labath <<a href="mailto:labath@google.com" class="">labath@google.com</a>> wrote:<br class=""><br class="">On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits<br class=""><<a href="mailto:lldb-commits@lists.llvm.org" class="">lldb-commits@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Author: vedantk<br class="">Date: Thu May 31 15:09:01 2018<br class="">New Revision: 333700<br class=""><br class="">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=333700&view=rev" class="">http://llvm.org/viewvc/llvm-project?rev=333700&view=rev</a><br class="">Log:<br class="">[IRMemoryMap] Test interleaved Mallocs and Frees<br class=""><br class="">This adds a new command to the ir-memory-map tester:<br class=""><br class=""> free <allocation-index><br class=""><br class="">The argument to free is an index which identifies which live allocation<br class="">to free. Index 0 identifies the first live allocation in the address<br class="">space, index 1 identifies the second, etc. where the allocations are<br class="">sorted in increasing order.<br class=""><br class="">For illustrative purposes, assume malloc returns monotonically<br class="">increasing addresses. Here are some examples of how free would work:<br class=""><br class="">Example 1<br class="">---------<br class=""><br class="">malloc 16 1<br class="">malloc 32 1<br class="">free 1 //< Free the 32-byte allocation.<br class="">free 0 //< Next, free the 16-byte allocation.<br class=""></blockquote><br class="">I think it would be better if the mallocs and frees were connected<br class="">symbolically instead of by an index that changes after every free. In<br class="">the long test case you add here it's pretty much impossible to figure<br class="">out which allocation a particular free refers to.<br class=""><br class="">Maybe we could<br class="">attach an optional "label" to each malloc statement and then have<br class="">"free" reference those? e.g. something like:<br class="">LARGEALLOC: malloc 4096 16<br class="">malloc 10, 1 # I won't free this, no label necessary<br class="">free LARGEALLOC # frees first allocation<br class=""><br class="">Adding parsing code for the extended syntax shouldn't be much work,<br class="">but I believe it will help a lot with the readability of these test<br class="">cases.<br class=""><br class="">WDYT?<br class=""></blockquote><br class="">I think this would be a good forward-looking change to make. Maybe it'll help test other parts of the API: we have no testing for WriteMemory, or for what happens on a double-free.<br class=""><br class="">As an aside, for this particular test case, I'm not sure there's a reason to figure out which allocation a free refers to. It might actually be sufficient to have the free command pick a random allocation to release (i.e, no arguments).<br class=""><br class="">vedant</div></div></blockquote></div><br class=""></div></body></html>