On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via cfe-dev
wrote:
>
> This has been on my mind for quite some time, but recently it's been popping
> up more and more seeing some of the issues people have run into.
>
> Before people get the wrong idea, let me make one thing clear. **I am not
> pr
Thanks for raising this.
This is a topic I've been interested in for a while too, as I've had to do
a few of those lite.site.cfg fix-ups that you mention (in fact I have one
sitting unreviewed at https://reviews.llvm.org/D40522 although I've not
pinged it in a long time so I'll need to double chec
Yes i listed 5 steps, but 2 of them (#2 and #5) are exactly what you
already do.
#1 I only actually do every couple of weeks, which is an improvement over
building inside VS. when you build inside vs you have to close and reopen
the solution every time you sync, which is really slow. You don’t act
> (in fact I have one sitting unreviewed at https://reviews.llvm.org/D40522
> although
>> I've not pinged it in a long time so I'll need to double check that it's
>> still an issue).
>>
>
Actually, ignore that. It's a slightly different issue that I had
mismembered as being related to https://re
On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell wrote:
> Thanks for raising this.
>
> This is a topic I've been interested in for a while too, as I've had to do
> a few of those lite.site.cfg fix-ups that you mention (in fact I have one
> sitting unreviewed at https://reviews.llvm.org/D40522 although
On Mon, Oct 8, 2018 at 11:54 AM Stephen Kelly via cfe-dev <
cfe-...@lists.llvm.org> wrote:
>
> > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still
> > fail sometimes. See this thread for details:
> > http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It
> > seem
> On Oct 8, 2018, at 8:09 AM, Zachary Turner via lldb-dev
> wrote:
>
> I haven't heard of anyone using the Xcode generated project. In fact, LLDB
> maintains its own hand-created Xcode project precisely because the CMake one
> is considered "unusable". That said, I don't personally use Xco
>
> Even if we do need to parse the line table, could it be done just for the
> function in question? The debug info tells us the function's address
> range, so is there some technical reason why it couldn't parse the line
> table only for the given address range?
>
My understanding is that there
I build with the VS project. I find it more convenient to do that than have VS
and a cmd window open to run ninja. Especially when I’ve got more than 1 copy
of VS open looking at different release trains. I wouldn’t mind using ninja to
build, but only if it worked when I right click on lldb and
A single sequence in the line table needs to be run from beginning to end to
make sense of it. It doesn't really have addresses, it generally has a start
address, then a sequence of "increment line, increment address" instructions.
So you have to run the state machine to figure out what the ad
I see. It's not the end of the world because I can just parse the whole
line table when requested. It's just that in PDB-land the format is such
that a) I know the exact address of the prologue and epilogue at the time I
parse the function record, and b) When parsing the line table, I can
quickly
On Mon, Oct 8, 2018 at 12:29 PM wrote:
> I build with the VS project. I find it more convenient to do that than
> have VS and a cmd window open to run ninja. Especially when I’ve got more
> than 1 copy of VS open looking at different release trains. I wouldn’t mind
> using ninja to build, but onl
I've had requests from several users now to change the default SIGPIPE handling
to "stop = false, notify = false". The argument is that most of the time these
signals are generally ignored and folks directly handle the read and write
errors. So having lldb stop by default for SIGPIPE is just a
13 matches
Mail list logo
