Hello,
I think it mostly works. i686-pc-windows-msvc + DWARF should definitely
work for basic things. x64 was never heavily tested simply due to it not
being my primary build configuration. I think all the hooks are in place,
so in theory it might work. If something's wrong I expect it won't b
Yea, adding a FORCE for a day or two and then removing the FORCE several
days later is a good way to handle this kind of thing.
On Tue, Nov 7, 2017 at 10:42 AM Reid Kleckner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> In general, please try to structure changes so that CMake cache clobbers
>
+1, this pattern looks like asking for UB
On Mon, Nov 20, 2017 at 11:57 AM Leonard Mosescu via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> void Clear() {
>> this->~ClassName();
>> new (this) ClassName();
>> }
>
>
> My 2c: this is clever, but not without downsid
On Tue, Nov 28, 2017 at 6:49 AM Daniel Olivier via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi.
>
> My goal is to process symbol files (i.e. PE-COFF/PDB, ELF/DWARF), and so I
> sought to examine how this is done in lldb. However, without first studying
> the code for an unreasonable amount of
Have you been able to run lldb under any sanitizers yet?
On Thu, Nov 30, 2017 at 12:24 PM Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hello,
>
> I've finished the LLVM TSan porting:
>
> https://blog.netbsd.org/tnf/entry/the_llvm_thread_sanitizer_has
>
> Next goal:
> Finish MS
A couple of things:
1) This bug is copy-pasted in 3 locations. That suggests to me that this
should be raised into a function that can be fixed once. Something like:
static void printNewLineIfNecessary(Stream &S, StringRef Format);
2) I don't think the new check does what you expect either. T
If we're going to be making any significant changes to the way inferiors
are compiled, why not use cmake? Make clean is already not implemented
correctly in many places, leading to lots of remnants left over in the
source tree after test runs. Furthermore, make is run every single time
currently,
I don't think new test authors really need to add CMake any more so than
they currently need to understand Make. Which is to say, not very much.
Most Makefiles are currently 1-2 lines of code that simply does nothing
other than include the common Makefile.
On the other hand, CMake defines a lot o
As a general rule, I support moving towards explicit run lines and
lit-style tests, but some care has to be taken. If you examine the common
Makefiles, you'll see that there's already a lot of special logic for
different platforms and compilers. It might be hard to maintain that if we
go back to
Note that we're going off topic from the original goal, and I just want to
re-iterate that I fully support smaller, incremental changes. But since I
like talking about lit so much, I can't help but chime in :)
If we *did* want to move to a lit based system for the end to end based
tests, the firs
On Wed, Jan 17, 2018 at 3:04 PM Adrian Prantl wrote:
>
> On the other hand:
> - everybody already knows make
>
I'm not sold on this particular reason. Make is not the LLVM build system,
CMake is. "I don't know the build system of the project I actually work
on, but I do know this other build s
I don't know what would be involved in getting the tests building out of
tree with Make. But I do know it would be simple with CMake. I'm sure
it's probably not terrible with Make either, I just don't know enough about
it to say.
One thing that I do like about CMake is that it can be integrated
On Wed, Jan 17, 2018 at 3:26 PM Greg Clayton wrote:
> I don't see why we would go with a lit based system that manually
> specifies the arguments. Seems like a pain to get the right compiler flags
> for creating shared libs on different systems (or executables, frameworks,
> etc). Seems like cmak
On Wed, Jan 17, 2018 at 3:39 PM Adrian Prantl wrote:
>
> On Jan 17, 2018, at 3:25 PM, Zachary Turner wrote:
>
> I don't know what would be involved in getting the tests building out of
> tree with Make. But I do know it would be simple with CMake. I'm sure
> it's probably not terrible with Mak
On Wed, Jan 17, 2018 at 3:44 PM Jim Ingham wrote:
>
> I don't see any of these operations that can't be done in a make file,
> after all you can run arbitrary commands there. We do make directories,
> dylibs, move and strip files, etc in some of the makefiles in the test case.
>
Make doesn't hav
What about doing a partial demangle? Take at most 1024 (for example)
characters from the mangled name, demangle that, and then display ... at
the end.
On Wed, Jan 24, 2018 at 3:48 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I have an issue where I am debugging a C++ binary
That's true, but shouldn't it be possible to demangle up until the last
point you got something meaningful? (I don't know the details of itanium
mangling, just assuming this is possible)
On Wed, Jan 24, 2018 at 3:54 PM Greg Clayton wrote:
> If you just cut off the string, then it might not dema
Great work. Have you tried (or considered) setting up an LLDB buildbot
that runs the LLDB test suite with all of the sanitizers turned on?
On Thu, Feb 1, 2018 at 5:39 AM Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I've finished the interruption for LLVM Sanitizers:
>
> http
On Tue, Feb 6, 2018 at 8:19 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> On 6 February 2018 at 15:41, Davide Italiano
> wrote:
> > On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote:
> >> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev
> >>
> >> So, I guess my quest
On Mon, Feb 5, 2018 at 8:12 PM Davide Italiano via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
>
> Conclusions:
> The reliability of the suite (and the health of the codebase) is very
> important to us. If you have issues, let us know.
> In general, I'm looking for any kind of feedback, feel free
On Wed, Feb 7, 2018 at 2:38 AM Pavel Labath wrote:
> On 6 February 2018 at 18:53, Zachary Turner wrote:
> > I'm not claiming that it's definitely caused by dotest and that moving
> away
> > from dotest is going to fix all the problems. Rather, I'm claiming that
> > dotest has an unknown amount
Best thing I can think of is to delete this test. This has come up several
times on the list. The reason the executable is checked in is because
otherwise we can't run the test on non-Windows. But given that this keeps
occurring, maybe we should just get rid of the test.
On Fri, Apr 6, 2018 at
We already don't really have any.
All of the makefiles that build the inferiors use a gcc style command line
syntax, and the way we made that work on Windows is to use clang for the
compiler. So MSVC is already out of the equation.
There may be one or two instances where we check in a PDB file,
On Thu, Apr 19, 2018 at 11:14 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> Also, looking at the tests for normalizing paths I found the following
> pairs of pre-normalized and post-normalization paths for posix:
>
> {"//", "//"},
> {"//net", "//net"},
>
> Why woul
On Thu, Apr 19, 2018 at 11:19 AM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> The last time I looked at the llvm functions they only support the path
> syntax of the llvm host, which won't do for lldb. But maybe they have
> gotten more general recently?
>
>
Yes in fact I was the on
We actually use it in some places, but it's limited. Before I did that was
when I added the PathSyntax to FileSpec which essentially servers the same
purpose. We could in theory drop PathSyntax now that LLVM supports all of
the same functionality. It's a pretty invasive refactor though which I
n
We don’t want the lowest levels of lldb to depend on clang. If this is
useful we should move it from clang to llvm and use llvm::VersionTuple
On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> No issues from me.
>
> > On May 8, 2018, at 9:11 AM, Pavel Laba
+davide, +aprantl for the Apple perspective.
On Tue, May 8, 2018 at 10:04 AM Greg Clayton wrote:
>
> On May 8, 2018, at 9:47 AM, Zachary Turner wrote:
>
> We don’t want the lowest levels of lldb to depend on clang. If this is
> useful we should move it from clang to llvm and use llvm::VersionTu
I assume you're referring to a windows minidump as opposed to a Mac core
file?
On Tue, Jun 5, 2018 at 4:19 PM Rustam Hashimov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi,
> lldb newbie here.
> Has anyone debugged minidump with lldb in MacOS. Any documentation or
> pointers would be apprec
For better or worse you need to make a separate function. An alternative
idea that has been floated is to start making a version 2 SB API and then
eventually deprecate the current API, but probably due to the amount of
work involved and the cost/benefit ratio, nobody's ever really taken point
on i
We can’t produce them, but you should check out the source code of google
breakpad / crashpad which can.
That said it’s a pretty simple format, there may be enough in our consumer
code that should allow you to produce them
On Wed, Jun 13, 2018 at 11:47 AM Greg Clayton wrote:
> I am interested in
;>> I've also pinged another Googler who I know might be interested in
>>> converting between minidumps and core files (the opposite direction) to see
>>> if he has any additional info. I don't think he's on lldb-dev, though, so
>>> I'll act as a r
oduced on. So LLDB gives us the connection to the live process,
> and we can then create a minidump file. I am going to create a python
> module that can do this for us.
>
> Greg
>
>
> On Jun 13, 2018, at 2:29 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org>
they are not examined in the machine that
>> they were produced on. So LLDB gives us the connection to the live process,
>> and we can then create a minidump file. I am going to create a python
>> module that can do this for us.
>>
>> Greg
>>
>>
>> O
find an object-file-reader/writer library. ELF may be more complicated
> though.
>
> > On Jun 13, 2018, at 2:51 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > What about the case where you already have a Unix core file and you
> aren
+1 for limiting the scope of a variable as much as possible
On Mon, Jun 18, 2018 at 7:57 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Thanks. I am going to submit the patch then.
>
> On Fri, 15 Jun 2018 at 19:56, Jim Ingham wrote:
> > > On Jun 15, 2018, at 3:44 AM, Pavel Labat
Hi all,
We have been thinking internally about a lightweight llvm-based ptracer.
To address one question up front: the primary way in which this differs
from LLDB is that it targets a more narrow use case -- there is no
scripting support, no clang integration, no dynamic extensibility, no
support
parser for C family languages that uses a
> different underlying representation than Clang AST's to store the results
> would be a lot of work that wouldn't be terribly interesting to lldb. I
> don't think that's what you meant, but wanted to be sure.
>
> Jim
>
>
Jun 26, 2018 at 12:26 PM Jim Ingham wrote:
> >> Just to be clear, by "no clang integration" do you mean "no expression
> parser" or do you mean something more radical? For instance, adding a
> TypeSystem and its DWARF parser for C family languages that uses a
>
On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl wrote:
>
>
> > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > We have been thinking internally about a lightweight llvm-based
> ptracer. To address one question up front: the prim
Ahh, thanks. I thought those changes never landed, but it's good to hear
that they did.
On Tue, Jun 26, 2018 at 1:49 PM Adrian Prantl wrote:
>
> > On Jun 26, 2018, at 1:38 PM, Zachary Turner wrote:
> >
> >> On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl
> wrote:
> >>
> >>> > On Jun 26, 2018, a
ser" or do you mean something more radical? For instance, adding a
> TypeSystem and its DWARF parser for C family languages that uses a
> different underlying representation than Clang AST's to store the results
> would be a lot of work that wouldn't be terribly interes
assumptions and requirements
On Wed, Jun 27, 2018 at 12:56 AM Pavel Labath wrote:
> On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev
> wrote:
> >
> > Yes that’s what I’ve been thinking about as well.
> >
> > One thing I’ve been giving a lot of thought to is whether
Plugin is a bit misleading. All “plugins” are compiled into lldb. Plugins
are really just a layering abstraction.
To answer your question, pdb works currently but is limited in
functionality. First, it only supports limited usage scenarios, and second
it requires Windows. It’s currently built on t
It’s been a while since i was close to this code, so adding people who have
been in there more recently
On Thu, Jul 5, 2018 at 1:12 PM Salahuddin Khan wrote:
> Hi Zachary,
>
>
>
> Ahh ok, thanks for your quick response.
>
>
>
> I was hoping to use LLDB on Windows (to debug Go code), which I know
Is it? If lldb is totally broken without that patch we should upstream it
no?
On Tue, Jul 10, 2018 at 8:52 PM Aaron Smith
wrote:
> This patch is needed for lldb to work on Windows.
>
> https://reviews.llvm.org/D12245
>
>
> --
> *From:* Zachary Turner
> *Sent:* Friday,
You might not get a reply but usually the turnaround time is < 24 hours.
If it's not let me know and I'll find out who to ask.
On Thu, Jul 12, 2018 at 7:50 AM NeckTwi via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I’m getting same error even if I debug on the same device.
>
> necktwi@pi:/home/n
Yea, removing them is probably fine.
On Tue, Jul 17, 2018 at 11:14 AM Stella Stamenova
wrote:
> Hey all,
>
>
>
> I’ve been looking at some of the test failures on Windows and this led me
> to realize that there are at least several tests that are duplicated
> between lldb-suite and the lit tests
This is really cool. Maybe you could do it for all of LLVM too? It would
be nice if, instead of cycling through each benchmark on a set interval,
there were just a dropdown box where you could select the one you wanted to
see.
On Fri, Aug 3, 2018 at 3:37 PM Raphael Isemann via lldb-dev <
lldb-de
I’ve thought about this in the past but the conclusion I came to is that
lldbinline tests are actually just filecheck tests in disguise. Why do we
need both? I’d rather delete the lldbinline infrastructure entirely and
make a new lit TestFormat that basically does what lldbinline already does
On Tu
On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar wrote:
>
>
> On Aug 14, 2018, at 5:34 PM, Zachary Turner wrote:
>
> I’ve thought about this in the past but the conclusion I came to is that
> lldbinline tests are actually just filecheck tests in disguise. Why do we
> need both? I’d rather delete the
Having bugs also makes the debugger harder to innovate in the future
because it’s, not having tests leads to having bugs, and sb api tests leads
to not having tests. At the end of the day, it doesn’t matter how stable
the tests are if there arent enough of them. There should be about 10x-20x
as man
On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote:
>
>
> > On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote:
> >
> > Having bugs also makes the debugger harder to innovate in the future
> because it’s, not having tests leads to having bugs, and sb api tests leads
> to not having te
>
> Yes, l
Back to the original proposal, my biggest concern is that a single inline
test could generate many FileCheck invocations. This could cause
measurable performance impact on the test suite. Have you considered this?
Another possible solution is what i mentioned earlier, basically to expose
a debug
What do your patches do, out of curiosity?
On Wed, Aug 15, 2018 at 12:45 PM Vedant Kumar wrote:
>
> On Aug 15, 2018, at 12:27 PM, Zachary Turner wrote:
>
> Back to the original proposal, my biggest concern is that a single inline
> test could generate many FileCheck invocations. This could cau
Various parts of lldb require knowing the source language. It’s possible
that things will mostly work if you report that the language is c++, but
you’ll probably get errors in other areas. It goes all the way down to the
CodeView level, where certain cv records indicate the original source
language
I think Aaron added that code for when the language is not set, but he can
clarify.
Off the top of my head I guess it helps with demangling symbols. Eg you
can’t demangle symbols from a TU without knowing what the language is.
There could be other reasons though. For example each language is going
I’m fine with it. I still would like to see inline tests ported to a custom
lit test format eventually, but this seems orthogonal to that and it can be
done in addition to this
On Thu, Aug 23, 2018 at 4:25 PM Vedant Kumar wrote:
> Pinging this because I'd like this to go forward to make testing e
It seems reasonable to me to say that if the symbol is not found in the
executables symtab, it will fall back to searching in the symbol file..
this logic doesn’t even need to be specific to PDB
On Thu, Aug 30, 2018 at 7:00 AM Aleksandr Urakov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hello
That would be my thought, yea
On Fri, Aug 31, 2018 at 1:21 AM Aleksandr Urakov <
aleksandr.ura...@jetbrains.com> wrote:
> Thanks for the reply!
>
> Yes, the function search is implemented in the way similar to what you
> have described (and even the search in a symbol file is done before the
> sea
I assume that reproducing race conditions is out of scope?
Also, will it be possible to incorporate these reproducers into the test
suite somehow? It would be nice if we could create a tar file similar to a
linkrepro, check in the tar file, and then have a test where you don't have
to write any p
By the way, several weeks / months ago I had an idea for exposing a
debugger object model. That would be one very powerful way to create
reproducers, but it would be a large effort. The idea is that if every
important part of your debugger is represented by some component in a
debugger object mod
but I think the problem space here
> is complicated enough already... You can't write a test if you don't know
> the correct end state.
>
> Jim
>
>
> > On Sep 19, 2018, at 10:59 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
Currently our PDBASTParser and SymbolFilePDB can only work on Windows
because it relies on a builtin Windows library.
In LLVM now we have full ability to read, parse, and interpret the contents
of PDB files at the byte level. There are two approaches to getting this
working in LLDB.
1) Re-implem
To clarify, #1 is saying to re-implement the API **in LLVM** so that LLDB
transparently just works with no code changes. While #2 is saying to
re-implement the plugin **in LLDB** to not use that API at all, and instead
use the low-level API that parses records directly from the file.
On Tue, Oct
While implementing native PDB support I noticed that LLDB is asking to
parse an entire compile unit's line table in order to determine if 1
address is a function prologue or epilogue.
Is this necessary in DWARF-land? It would be nice if I could just pass the
prologue and epilogue byte size direct
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
proposing we stop supporting the CMake Visual Studio generator. I am only
propos
What would the variable do? Ninja and VS are generators, the only way to
specify them is with the -G option to cmake. If you use the VS generator,
there's no way I'm aware of to make it use ninja instead of MSBuild when
you hit Ctrl+Shift+B.
That said, type ninja in a command prompt is not a ter
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
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
s 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's one DWARF .debug_line "program" per CU,
> and normally you'd need to &qu
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
On Tue, Oct 9, 2018 at 12:49 AM Csaba Raduly wrote:
> On Sun, Oct 7, 2018 at 10:51 PM Zachary Turner via cfe-dev
> wrote:
>
> > 1) Run CMake twice, generating to separate output directories. Once
> using -G "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
> >
>
So IIUC this all 1 big solution, one component of which is LLVM? How do you
get them all together in 1 big solution?
On Wed, Oct 10, 2018 at 7:16 AM Nicolas Capens
wrote:
> Hi Zachary,
>
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
> (Emulator). Most development ta
I was trying to implemented type lookup for qualified names (e.g. in
namespaces), and I noticed we have this code in Module.cpp:
if (Type::GetTypeScopeAndBasename(type_name_cstr, type_scope,
type_basename,
type_class)) {
// Check if "name" starts with "::"
Hello,
I've got this code:
class Class {
int x = 0;
short y = 1;
char z = 'z';
} C;
int main(int argc, char **argv) {
__debugbreak();
return 0;
}
and I run the following LLDB session:
lldb.exe -f foo.exe
(lldb) target create "foo.exe"
Current executable set to 'foo.exe' (x86_64).
(ll
Note that I also tried this with a a linux / DWARF executable and had the
same result.
On Fri, Oct 26, 2018 at 3:21 AM Zachary Turner wrote:
> Hello,
>
> I've got this code:
>
> class Class {
> int x = 0;
> short y = 1;
> char z = 'z';
> } C;
>
> int main(int argc, char **argv) {
> __deb
So, the second command works, but the first one doesn't. It doesn't give
any error, but on the other hand, it doesn't change the results of printing
the variable. When I run type category list though, I get this:
(lldb) type category list
Category: default (enabled)
Category: VectorTypes (enable
Ok that was it, it was because my type was called Class. Oops!
On Fri, Oct 26, 2018 at 4:28 PM Jim Ingham wrote:
> Most C++ classes and C structs don't have data formatters, particularly
> not classes that you write yourself.
>
> The way value printing works in lldb is that we start by making the
It seems like we hit this issue in different contexts almost at the same
time (see my thread several days ago about “problem formatting value
objects”). That might at least give you some context about why things
I wish ObjC assumptions weren’t so deeply embedded, but alas it is the case.
Hopefull
The first thing I would try is to see where the language is getting set to
objective c and force it c++. Just as an experiment. Depending where it
happens, it may be possible to initialize it from the debug info (or
hardcode it).
But since ObjC assumptions are baked into several places, this has
p
I can tell you that in LLDB we already do get CC'ed on the list for every
bug. I will grant you that the volume of bugs in LLDB is much lower than
other lists, but I find it very helpful. It gives visibility to bugs that
would otherwise be seen by nobody.
On the other hand, I'm intentionally uns
I don’t totally agree with this. I think there are a lot of useful os
awareness tasks in user mode. For example, you’re debugging a deadlock and
want to understand the state of other mutexes, who owns them, etc. or you
want to examine open file descriptors. In the case of a heap corruption you
may
Just so I'm clear, are we going to attempt to clean up and/or merge the
components? If we are, it makes sense to do that before we start putting
ourselves as default CC's on the various components since they will just
change. If not, it would be nice to get some clarification on that now.
I've p
To elaborate, I didn't mean to group all components with less than 10 bugs
into one massive component. Rather, to do it separately for each
subcomponent. Grouping by expertise is fine, but I would argue that a
component with 2 or 3 bugs filed per year is not a very useful component.
There has to
I had considered a libraries/Backends:Other as well that would be separate
from libraries/Other
On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff wrote:
> I wonder if backends are a special case to the heuristic of "let's not
> make a bug component for code components that are too small". LLVM is
>
I tried to run this command:
(lldb) target variable "std::numeric_limits::max_exponent"
In Variable.cpp:386 we run a regex against the input string which results
in the above string being cut down to just `std::numeric_limits`. So then
I search my debug info and don't find anything.
What I need
One of the issues we've faced a couple of times (and will continue to face)
is that lit is generally built around substitutions and command lines, but
different compilers will generally have different substitutions, and worse
-- different command line syntaxes.
The most recent example of this is t
On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I would appreciate, if someone could point me to some relevant code that
> does something similar to what I'm asking, so I could use it as a base
> point for exploration.
>
> Many thanks.
Not sur
Have you tried an strace to see if it tells you who is sending the signal?
On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> Since we switched to lit as the test driver we've been seeing it getting
> killed as the result of a SIGHUP
at 9:12 PM Jonas Devlieghere
wrote:
>
>
> On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Have you tried an strace to see if it tells you who is sending the signal?
>
>
> I used DTrace with the default ki
Is there some reason we can’t define vendors, environments, arches, and
oses for all supported use cases? That way “there is no os” would not ever
be a thing.
On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I think the confusing thing is when "unspecif
That's what I mean though, perhaps we could add a value to the OSType
enumeration like BareMetal or None to explicitly represent this. the
SubArchType enum has NoSubArch, so it's not without precedent. As long as
you can express it in the triple format, the problem goes away.
On Thu, Dec 6, 2018
We can already say that with OSType::Unknown. That’s different than “i know
that no OS exists”
On Fri, Dec 7, 2018 at 12:00 AM Pavel Labath wrote:
> On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
> > Oh sorry I missed that. Yes, I think a value added to the OSType for
> NoOS or something
mm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
>
> *From:* lldb-dev *On Behalf Of *Zachary
> Turner via lldb-dev
> *Sent:* Friday, December 7, 2018 4:38 AM
> *To:* Pavel Labath
> *Cc:* LLDB
> *Subject:* Re: [lldb-d
I don't think #2 is a correct change. Just because the sign bit is set
doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
unsigned? It's a trick question, because there's not enough information!
If it was written "int x = 0x1000" then it's signed (and negative). If
it was wr
On Fri, Jan 4, 2019 at 3:23 PM Jonas Devlieghere
wrote:
> On Fri, Jan 4, 2019 at 3:13 PM Zachary Turner wrote:
>
>> I don't think #2 is a correct change. Just because the sign bit is set
>> doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
>> unsigned? It's a trick question,
It seems like we have 3 uses of this constructor in LLDB.
IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant.
IRForTarget.cpp: Constructs a Scalar for an llvm::Constant.
ClangASTContext.cpp: bitcasts an APFloat to an APInt.
The first two we should just treat constants in LLVM IR as sig
I'd be curious to see if the PID of the process that is failed to attach to
is the same as one of the PIDs of a process that was previously attached to
(and if so, if it is the first such case where a PID is recycled).
On Sat, Jan 5, 2019 at 4:42 AM Florian Weimer via lldb-dev <
lldb-dev@lists.llv
401 - 500 of 635 matches
Mail list logo
