Ø We can solve the same sort of challenge (the desire to eject old autoupgrade
code) by having a sliding window of versions supported (e.g. version 4.5
supports back to version 3.6).
How easy/hard is it to identify the minor release associated with a particular
auto-upgrade feature? My impres
For what it is worth, I fully support *any* change that moves us away
from having our own infrastructure. We should really stop hosting our
own code repositories, databases and mailing lists.
For that, I support the proposal to move to github, but would also
support moving to another hosting servi
Hi Greg,
Thanks for your reply. I did try the method you mention above but
variable.GetLocation() only provide me the memory address of the variable.
What exactly I am looking for was the register offset that stores variable
i here. Example, I am looking for method able to output the one highligh
We currently don't expose this information through the API, though we could.
You could add a new method to SBValue:
namespace lldb
{
class SBValue
{
SBData GetDWARFLocation();
}
};
This could return the DWARF location as a SBData object. Then you could consume
the data by parsing the
https://llvm.org/bugs/show_bug.cgi?id=28253
Bug ID: 28253
Summary: lldb-mi Regression with LLDB_DISABLE_PYTHON=1
Product: lldb
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Hi Ilia,
Thanks for the reply. I did #1 for our workaround for the time being and opened
https://llvm.org/bugs/show_bug.cgi?id=28253.
Thanks!
-Pierson
From: Ilia K [mailto:ki.s...@gmail.com]
Sent: Monday, June 20, 2016 1:45 AM
To: Pierson Lee (PIE)
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lld
