- User Since
- Jan 10 2013, 2:43 PM (471 w, 1 h)
The background here is that I found this patch in one of my old WIP branches. The next patch in the series was going to define LLDB_API to __attribute__((visibility("default"))) on the non-windows path (and make everything else hidden), but I have no idea why I wanted to do that. I mean, it does not sounds like an *un*reasonable thing to do, but am not going to do unless I find some benefit to it (maybe it saves size?)
So what happens now if you define LLDB_IN_LIBLLDB? Does dllexport explode if used in a static library?
Before this change, it was very easy to build liblldb as a static library (just don't define IMPORT_LIBLLDB and EXPORT_LIBLLDB). After this change, this is no longer possible on Windows (but it still works fine everywhere else). Is this intentional?
Tue, Jan 18
This breaks tests on windows: http://126.96.36.199/win/52841/step_7.txt
Fri, Jan 14
Breaks a few tests on windows too: http://188.8.131.52/win/52616/step_7.txt
This breaks a bunch of tests on Mac: http://184.108.40.206/macm1/25623/step_7.txt
Thu, Jan 13
Could use a short comment on how to use it ("build in one build dir with propellor_phase = 1, run perf, ...") maybe.
Since this is changing serialization format you might have to do something like https://reviews.llvm.org/rGb8b7a9dcdcbc as well (see https://reviews.llvm.org/D73202 for background). I doubt that's the cause of mstorsjo's repro given that LLVM_APPEND_VC_REV is on by default, but it seems like a good thing to do in the reland regardless.
Wed, Jan 12
(Reverted for now.)
This breaks tests on windows: http://220.127.116.11/win/52389/step_11.txt
Tue, Jan 11
The test fails on Windows: http://18.104.22.168/win/52360/step_11.txt
Seems to not fail every time though.
This seems to break tests: http://22.214.171.124/macm1/25367/step_10.txt
Nice! lgtm. One bikeshed comment about naming below (in two places, but about the same name).
That was easy :) Thanks!
That's referring to the fact that once we allocate new DirectoryLookup with SpecificBumpPtrAllocator, address of that object won't change (unlike with std::vector). This means that we can take the address and use it without worrying about invalidation.
- which is stable thanks to the bump-ptr-allocation strategy. I don't understand this. In each slab, that's true, but why is it true between objects allocated in different slabs?
- This increases numbers of TUs compiled for LexTests by over 10%. Is there no way around that Frontend dep?
Mon, Jan 10
Looks like this breaks tests: http://126.96.36.199/linux/64726/step_8.txt
Fri, Jan 7
Thanks for the patch!
Thu, Jan 6
Should we just land this and see what (if any) breaks?
For "why 100": My repro worked with 10, so I figured if I put in ten times that nobody should ever hit this again. Looks like that didn't work out 😓
Wed, Jan 5
Not sure what happened here but this change added back a whole bunch of old code. I reverted this in 085f078307bac264301b07f6e47e2a04e90a6f1d . Please carefully check git diff origin/main before committing next time :)
Tue, Jan 4
Thanks for noticing that. It's back and happy now.
Mon, Jan 3
Still broken on windows: http://188.8.131.52/win/51764/step_4.txt
Breaks building on windows: http://184.108.40.206/win/51774/step_4.txt
Sat, Jan 1
Thanks for the patch! This looks roughly right to me.
Thu, Dec 23
Wed, Dec 22
If this code is truly dead, this looks fine to me.
Dec 21 2021
Dec 20 2021
Looks like this broke check-llvm: https://lab.llvm.org/buildbot/#/builders/109/builds/28397
Dec 17 2021
Dec 16 2021
reverted in 770ef94097c02205b3ec9e902f1d6a9c99b5189c. thanks!
This breaks tests on macOS: http://220.127.116.11/macm1/23920/step_7.txt