Patch up for review: https://reviews.llvm.org/D47646 <https://reviews.llvm.org/D47646>
thanks, vedant > On Jun 1, 2018, at 11:31 AM, Vedant Kumar <v...@apple.com> wrote: > > > >> On Jun 1, 2018, at 1:39 AM, Pavel Labath <lab...@google.com> wrote: >> >> On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits >> <lldb-commits@lists.llvm.org> wrote: >>> >>> Author: vedantk >>> Date: Thu May 31 15:09:01 2018 >>> New Revision: 333700 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=333700&view=rev >>> Log: >>> [IRMemoryMap] Test interleaved Mallocs and Frees >>> >>> This adds a new command to the ir-memory-map tester: >>> >>> free <allocation-index> >>> >>> The argument to free is an index which identifies which live allocation >>> to free. Index 0 identifies the first live allocation in the address >>> space, index 1 identifies the second, etc. where the allocations are >>> sorted in increasing order. >>> >>> For illustrative purposes, assume malloc returns monotonically >>> increasing addresses. Here are some examples of how free would work: >>> >>> Example 1 >>> --------- >>> >>> malloc 16 1 >>> malloc 32 1 >>> free 1 //< Free the 32-byte allocation. >>> free 0 //< Next, free the 16-byte allocation. >> >> I think it would be better if the mallocs and frees were connected >> symbolically instead of by an index that changes after every free. In >> the long test case you add here it's pretty much impossible to figure >> out which allocation a particular free refers to. >> >> Maybe we could >> attach an optional "label" to each malloc statement and then have >> "free" reference those? e.g. something like: >> LARGEALLOC: malloc 4096 16 >> malloc 10, 1 # I won't free this, no label necessary >> free LARGEALLOC # frees first allocation >> >> Adding parsing code for the extended syntax shouldn't be much work, >> but I believe it will help a lot with the readability of these test >> cases. >> >> WDYT? > > 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. > > 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). > > vedant
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
