[lldb-dev] [Bug 36146] New: TestWithGmodulesDebugInfo.test_specialized_typedef_from_pch_gmodules fails on i386 linux
https://bugs.llvm.org/show_bug.cgi?id=36146 Bug ID: 36146 Summary: TestWithGmodulesDebugInfo.test_specialized_typedef_fro m_pch_gmodules fails on i386 linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2769: unsigned int ObjectFileELF::ApplyRelocations(lldb_private::Symtab *, const elf::ELFHeader *, const elf::ELFSectionHeader *, const elf::ELFSectionHeader *, const elf::ELFSectionHeader *, lldb_private::DataExtractor &, lldb_private::DataExtractor &, lldb_private::DataExtractor &, lldb_private::Section *): Assertion `false && "unexpected relocation type"' failed. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Rust language support question
On 29 January 2018 at 18:39, Tom Tromey wrote: >> "Pavel" == Pavel Labath writes: > > Pavel> To these very insightful emails from Greg and Jim, I'd just like to > Pavel> add one request. Please consider the testing strategy of the code you > Pavel> write early on. One of the problems that we have with these language > Pavel> plugins (and why we now have a separate thread considering removal of > Pavel> some of them) is that after the plugin has landed and some time has > Pavel> elapsed with no activity on it, we have no idea if it is even still > Pavel> functional without any tests. > > So far I've added code in packages/Python/lldbsuite/test to support Rust > and then I have a simple Rust program that exercises the various > features of the plugin. > > The Rust toolchain is very easy to install, so I don't think testing > this in the future should be too difficult. Yes, but it still adds another manual step to the setup process, which means most developers will not do it. It also exposes us to a non-determinism coming from different versions of the rust compiler people will have. What happened with go is that the developer who contributed the go support disappeared after a while. Then a couple of months later, go version on my machine got updated, and some go tests started failing. Maintaining go support is not my job, but I would still love to make sure that my (unrelated) changes don't regress go debugging functionality. However, I'm not going to go and add support for a new go compiler just so I can run the existing tests, so I disabled the go tests on my end (which was quite tricky as all google machines force-install go). For comparison, there's a thread on llvm-dev right now about checking in integer set library into llvm repo, and the main argument seems to be that it will make tests more deterministic. > > I am not sure of the details yet, but for expression parsing, I would > like to get the external helper into "rustup" (the Rust toolchain > manager) as well. > > Pavel> (maybe via llvm/DWARFYAML) > > What is a good resource for learning about this? I don't know anything other than source code. llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp is a good place to see it in action. Right now there doesn't seem to be an executable which exposes this functionality to play with (it's just a library), but I'm sure we could add one if it proves useful. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
Right, so, independently of this thread here, we've had an internal discussion about reviving java support. However, it is still very uncertain that this will actually happen , so I'm not opposed to removing it as we can always add it back later (with better testing, hopefully). Regardless of what happens here (and in light of the rust thread), I think a clearer bar for what we expect from new language support plugin would be useful for everyone. pl On 22 January 2018 at 20:13, Jim Ingham wrote: > To Davide's alternative: LLDB does handle loading plugins that use the SB > API's (for things like data formatters.) But there's not currently an SB > interface to support > writing a full language plugin, and we don't export the lldb_private API's > from the lldb binary. So there's no current mechanism to provide out-of-tree > language plugins. It would be great to enable out-of-tree language support > mechanisms but we would have to design an SB interface for that purpose. > > I see occasional questions about using Go with lldb on stack overflow and the > like. It might be good to put out a more general "anybody interested in > supporting this" call for Go, but I'm not sure the lldb-dev list is the best > place to find an owner. Is there some Go dev list we can ask to see if > anybody cares to support this? > > Non-stop never actually worked, it was just a promise, and the code for it > was pretty thin. I would be okay with pulling that out unless somebody is > actually getting good use out of it. > > Jim > >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev >> wrote: >> >> The Go support for added by Ryan as a 20% project. Now that he's no >> longer working for Google, it's pretty much abandoned. >> The Java support was added by us (android folks) to support java >> debugging (to a certain extent). However, we never really finished the >> project, so we're not using that code now. We're hoping to come back >> to it one day, but I agree we should not burden everyone else while we >> make up our mind on that. >> >> So I don't think anybody would shout at us if we removed them right >> now, but maybe we should make some effort to find a maintainer for >> them before removal? E.g. publicly declare that they are going to be >> deleted on date unless a maintainer steps up to take care of them >> (we can define the minimum level of support we'd expect from such a >> maintainer). Then I can e.g. forward the email to the Google Go folks >> and see if anyone of them wants to take that up. >> >> As for Java, I'm going to bring up the desire to remove the Java >> plugin on our team's meeting this week and get back to you with the >> result. >> >> >> In general I think that a clear deprecation/removal process would be >> nice to have. I have a couple of things I think are broken/unused >> (PlatformKalimba? non-stop mode?) but I haven't brought them up >> because I was unsure how to handle it. >> >> >> On 22 January 2018 at 15:28, Davide Italiano wrote: >>> Hi, >>> during my wandering I stumbled upon the `Go` and the `Java` plugins in >>> the lldb source tree. >>> They seem to not have been touched in a while, and I'm not necessarily >>> sure they're in a working state. Keeping them in tree is a maintenance >>> burden, so unless somebody is actively using them or somebody is >>> willing to step up as maintainers, I'm not necessarily sure we should >>> pay this price. >>> >>> An alternative would be that of having a pluggable mechanism to add >>> language support (I haven't fleshed out the details of this yet, but >>> it should be possible, somehow). Other languages which have out of >>> tree support might benefit from this (e.g. Swift/Rust). >>> >>> Thoughts? >>> >>> -- >>> Davide >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
Originally I added the Java support to work with the Android ART runtime and it has some pretty hard beaked in dependencies on the debug info ART generates and on the version of ART available at that time (Android N) even though I don't think this limitation is communicated clearly in source code or in code reviews. Considering that AFAIK it haven't been tested with Android O and haven't seen any bugfix for a while I would assume it is mostly unused so I am happy to get it removed. And as Pavel said if somebody want to use it again we can always add it back in with a better testing strategy and long term plan. Generally for new language support I think we should have a similar policy then what LLVM have for new backends. They should be developed out of tree first without us providing a stable API (developer can fork a specific version of LLDB, preferably upstream language independent bugfixes and then pull in new changes once in a while) and if they are mature enough both in terms of testing and maintenance commitment then they can be pulled into the main LLDB source tree. Tamas On Tue, Jan 30, 2018 at 11:52 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Right, so, independently of this thread here, we've had an internal > discussion about reviving java support. However, it is still very > uncertain that this will actually happen , so I'm not opposed to > removing it as we can always add it back later (with better testing, > hopefully). > > Regardless of what happens here (and in light of the rust thread), I > think a clearer bar for what we expect from new language support > plugin would be useful for everyone. > > pl > > On 22 January 2018 at 20:13, Jim Ingham wrote: > > To Davide's alternative: LLDB does handle loading plugins that use the > SB API's (for things like data formatters.) But there's not currently an > SB interface to support > > writing a full language plugin, and we don't export the lldb_private > API's from the lldb binary. So there's no current mechanism to provide > out-of-tree language plugins. It would be great to enable out-of-tree > language support mechanisms but we would have to design an SB interface for > that purpose. > > > > I see occasional questions about using Go with lldb on stack overflow > and the like. It might be good to put out a more general "anybody > interested in supporting this" call for Go, but I'm not sure the lldb-dev > list is the best place to find an owner. Is there some Go dev list we can > ask to see if anybody cares to support this? > > > > Non-stop never actually worked, it was just a promise, and the code for > it was pretty thin. I would be okay with pulling that out unless somebody > is actually getting good use out of it. > > > > Jim > > > >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> The Go support for added by Ryan as a 20% project. Now that he's no > >> longer working for Google, it's pretty much abandoned. > >> The Java support was added by us (android folks) to support java > >> debugging (to a certain extent). However, we never really finished the > >> project, so we're not using that code now. We're hoping to come back > >> to it one day, but I agree we should not burden everyone else while we > >> make up our mind on that. > >> > >> So I don't think anybody would shout at us if we removed them right > >> now, but maybe we should make some effort to find a maintainer for > >> them before removal? E.g. publicly declare that they are going to be > >> deleted on date unless a maintainer steps up to take care of them > >> (we can define the minimum level of support we'd expect from such a > >> maintainer). Then I can e.g. forward the email to the Google Go folks > >> and see if anyone of them wants to take that up. > >> > >> As for Java, I'm going to bring up the desire to remove the Java > >> plugin on our team's meeting this week and get back to you with the > >> result. > >> > >> > >> In general I think that a clear deprecation/removal process would be > >> nice to have. I have a couple of things I think are broken/unused > >> (PlatformKalimba? non-stop mode?) but I haven't brought them up > >> because I was unsure how to handle it. > >> > >> > >> On 22 January 2018 at 15:28, Davide Italiano > wrote: > >>> Hi, > >>> during my wandering I stumbled upon the `Go` and the `Java` plugins in > >>> the lldb source tree. > >>> They seem to not have been touched in a while, and I'm not necessarily > >>> sure they're in a working state. Keeping them in tree is a maintenance > >>> burden, so unless somebody is actively using them or somebody is > >>> willing to step up as maintainers, I'm not necessarily sure we should > >>> pay this price. > >>> > >>> An alternative would be that of having a pluggable mechanism to add > >>> language support (I haven't fleshed out the details of this yet, but > >>> it should be possible, somehow). Other languages which have out of
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document specifies that the case folding should be done according the the "Caseless matching" Section of the Unicode standard (whose implementation is basically a long list of special cases). While certainly possible, implementing this would be much more complicated (and would probably make the code a bit slower) than a simple tolower(3) call. And the benefits of this are not really clear to me. Do you know if we already make any promises or assumptions about the encoding and/or locale of the symbol names (and here I mainly mean the names in the debug info metadata, not llvm symbols). If we don't already have a policy about this, then I propose to implement the case folding via tolower() (which is compatible with the full case folding algorithm, as long as one sticks to basic latin characters). What do you think? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Rust language support question
> "Pavel" == Pavel Labath writes: Pavel> Yes, but it still adds another manual step to the setup process, which Pavel> means most developers will not do it. It also exposes us to a Pavel> non-determinism coming from different versions of the rust compiler Pavel> people will have. I see what you mean, but if the Rust plugin isn't updated for new versions of the Rust compiler, it just won't be very useful to Rust developers. This could happen, but I think the best approach here is more communication. If newer versions of Rust break the tests, and you don't hear from the Rust community, ask someone what's going on. For older versions, what I understand is that Rust doesn't remove old toolchains. So you can still install older ones for testing. For testing LLDB changes unrelated to Rust, you can just install some known-working toolchain. My plan is to support some reasonable range -- starting with whatever toolchain is stable at the time the Rust plugin is ready to be used. Mostly I'm trying to avoid writing a lot of custom DWARF tests. That seems like a lot of work for not a lot of benefit. And from what I understand (correct me if I'm wrong), I'd be the first to being doing this, so I'd probably have to write the tooling, etc. Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote: > > Hello all, > > I am looking for feedback regarding implementation of the case folding > algorithm for .debug_names hashes. > > Unlike the apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-insensitive lookups for languages > where that makes sense). The dwarf5 document specifies that the case > folding should be done according the the "Caseless matching" Section > of the Unicode standard (whose implementation is basically a long list > of special cases). While certainly possible, implementing this would > be much more complicated (and would probably make the code a bit > slower) than a simple tolower(3) call. And the benefits of this are > not really clear to me. Assuming a UTF-8 encoding, will tolower(3) destroy any non-ASCII characters in the process? In Swift, for example, we allow a wide range of unicode characters in identifiers and I want to make sure that this doesn't cause any problems. -- adrian > > Do you know if we already make any promises or assumptions about the > encoding and/or locale of the symbol names (and here I mainly mean the > names in the debug info metadata, not llvm symbols). > > If we don't already have a policy about this, then I propose to > implement the case folding via tolower() (which is compatible with the > full case folding algorithm, as long as one sticks to basic latin > characters). > > What do you think? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
On 30 January 2018 at 15:41, Adrian Prantl wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the apple tables, the .debug_names hashes are computed from >> case-folded names (to enable case-insensitive lookups for languages >> where that makes sense). The dwarf5 document specifies that the case >> folding should be done according the the "Caseless matching" Section >> of the Unicode standard (whose implementation is basically a long list >> of special cases). While certainly possible, implementing this would >> be much more complicated (and would probably make the code a bit >> slower) than a simple tolower(3) call. And the benefits of this are >> not really clear to me. > > Assuming a UTF-8 encoding, will tolower(3) destroy any non-ASCII characters > in the process? In Swift, for example, we allow a wide range of unicode > characters in identifiers and I want to make sure that this doesn't cause any > problems. > I'm not sure what it will do out-of-the-box, but I could certainly implement it such that it does not touch the fancy characters. However, if we already have unicode characters in the input, then it may make sense to go all the way and implement the full folding algorithm. Because, once we start producing hashes like this, it will be hard to switch to being fully standard-compliant (as that would invalidate the existing hashes). But the question then is: can I assume the input names will be unicode (w/utf8 encoding)? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
> On Jan 30, 2018, at 3:35 PM, Pavel Labath wrote: > > Hello all, > > I am looking for feedback regarding implementation of the case folding > algorithm for .debug_names hashes. > > Unlike the apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-insensitive lookups for languages > where that makes sense). The dwarf5 document specifies that the case > folding should be done according the the "Caseless matching" Section > of the Unicode standard (whose implementation is basically a long list > of special cases). While certainly possible, implementing this would > be much more complicated (and would probably make the code a bit > slower) than a simple tolower(3) call. Most of the characters in the CaseFolding.txt file seem to be contiguous, so I think we should be able to come up with am implementation that’s relatively efficient. > And the benefits of this are not really clear to me. Adhering to the standard is a pretty big benefit IMHO, but I know what you mean. :-) > Do you know if we already make any promises or assumptions about the > encoding and/or locale of the symbol names (and here I mainly mean the > names in the debug info metadata, not llvm symbols). > > If we don't already have a policy about this, then I propose to > implement the case folding via tolower() (which is compatible with the > full case folding algorithm, as long as one sticks to basic latin > characters). > > What do you think? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
> On Jan 30, 2018, at 7:49 AM, Pavel Labath wrote: > > On 30 January 2018 at 15:41, Adrian Prantl wrote: >> >> >>> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote: >>> >>> Hello all, >>> >>> I am looking for feedback regarding implementation of the case folding >>> algorithm for .debug_names hashes. >>> >>> Unlike the apple tables, the .debug_names hashes are computed from >>> case-folded names (to enable case-insensitive lookups for languages >>> where that makes sense). The dwarf5 document specifies that the case >>> folding should be done according the the "Caseless matching" Section >>> of the Unicode standard (whose implementation is basically a long list >>> of special cases). While certainly possible, implementing this would >>> be much more complicated (and would probably make the code a bit >>> slower) than a simple tolower(3) call. And the benefits of this are >>> not really clear to me. >> >> Assuming a UTF-8 encoding, will tolower(3) destroy any non-ASCII characters >> in the process? In Swift, for example, we allow a wide range of unicode >> characters in identifiers and I want to make sure that this doesn't cause >> any problems. >> > > I'm not sure what it will do out-of-the-box, but I could certainly > implement it such that it does not touch the fancy characters. > > However, if we already have unicode characters in the input, then it > may make sense to go all the way and implement the full folding > algorithm. Because, once we start producing hashes like this, it will > be hard to switch to being fully standard-compliant (as that would > invalidate the existing hashes). > > But the question then is: can I assume the input names will be unicode > (w/utf8 encoding)? We can make that happen and encode it explicitly in each compile unit: > 3.1.1 Full and Partial Compilation Unit Entries > ... > A DW_AT_use_UTF8 attribute, which is a flag whose presence indicates that all > strings (such as the names of declared entities in the source program, or > filenames in the line number table) are represented using the UTF-8 > representation. -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm
On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to llvm-dwarfdump via the DebugInfo > library (to enable testing of the table generation) FYI FSF binutils readelf can read .debug_names already for some possible format cross-check (to prevent multiple incompatible implementations). > 2. add .debug_names generation support (not enabled by default) + > I also have a very basic implementation of (2), but this is still quite far > from being upstreamable. Originally I expected I will reuse the GDB .debug_names producer for LLVM: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=437afbb81e3a04cbd933fc534a50c686eaa63b19 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=8af5c486ea6153bb84b9257def4e5faa4bc72421 But I see you were faster. Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36155] New: FastDemangle performance problem
https://bugs.llvm.org/show_bug.cgi?id=36155 Bug ID: 36155 Summary: FastDemangle performance problem Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: feishenni...@gmail.com CC: llvm-b...@lists.llvm.org Here's a simple python program that generates a mangled string with size n: def gen(n): prefix = '_Z0' suffix = 'Mm0' content = 'M0' * (n-6) return prefix + content + suffix lldb's FastDemangler exhibit quadratic behavior when demangling such a string. On my laptop (2015 Thinkpad t440p Arch Linux), setting n to ~2 will cause a noticable slowdown, and ~5 would just segfault the program. The same inputs are rejected instantly by itaniumDemangle() as well as c++filt. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36156] New: lldb-mi does not report watchpoint stops
https://bugs.llvm.org/show_bug.cgi?id=36156
Bug ID: 36156
Summary: lldb-mi does not report watchpoint stops
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ted.woodw...@codeaurora.org
CC: llvm-b...@lists.llvm.org
When lldb-mi hits a watchpoint, the process stops, but this stop isn't
reported.
Take this simple program:
int glob = 1;
int main(void)
{
glob = 2;
while (1)
;
return glob;
}
On Ubuntu 14.04 x86_64, I built it with clang 3.8 and debugged with lldb-mi
top-of-tree. When I run and set a watchpoint on glob, it fails to report the
stop.
***launch program, stop at main***
>bin/lldb-mi foo
(gdb)
-file-exec-and-symbols "foo"
^done
(gdb)
=library-loaded,id="/local/mnt/ted/tip/full/foo",target-name="/local/mnt/ted/tip/full/foo",host-name="/local/mnt/ted/tip/full/foo",symbols-loaded="0",loaded_addr="-",size="0"
b main
~"Breakpoint 1: where = foo`main + 11 at foo.c:5, address =
0x004004fb\n"
^done
(gdb)
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x004004fb",func="main",file="foo.c",fullname="/local/mnt/ted/tip/full/foo.c",line="5",times="0",original-location="foo.c:5"}
(gdb)
r
~"Process 27861 launched: '/local/mnt/ted/tip/full/foo' (x86_64)\n"
^done
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x004004fb",func="main",file="foo.c",fullname="/local/mnt/ted/tip/full/foo.c",line="5",times="0",original-location="foo.c:5"}
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-loaded,id="/local/mnt/ted/tip/full/foo",target-name="/local/mnt/ted/tip/full/foo",host-name="/local/mnt/ted/tip/full/foo",symbols-loaded="0",loaded_addr="-",size="0"
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
=library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so",loaded_addr="-",size="0"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",loaded_addr="-",size="0"
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x004004fb",func="main",args=[],file="foo.c",fullname="/local/mnt/ted/tip/full/foo.c",line="5"},thread-id="1",stopped-threads="all"
(gdb)
***set the watchpoint and continue***
w s v glob
~"Watchpoint created: Watchpoint 1: addr = 0x00601038 size = 4 state = enabled
type = w\ndeclare @ '/local/mnt/ted/tip/full/foo.c:1'\nwatchpoint spec
= 'glob'\nnew value: 1\n"
^done
(gdb)
-exec-continue
^running
(gdb)
=thread-exited,id="1",group-id="i1"
(gdb)
*running,thread-id="all"
(gdb)
=thread-created,id="1",group-id="i1"
(gdb)
lldb-mi reported thread-exited for thread 1, but the thread is still there, and
stopped at the watchpoint:
process status
~"Process 27861 stopped\n* thread #1, name = 'foo', stop reason = watchpoint
1\nframe #0: 0x00400506 foo`main at foo.c:6\n 3 \tint
main(void)\n 4 \t{\n 5 \t glob = 2;\n-> 6 \t \e[4mw\e[0mhile (1)\n
7 \t;\n 8 \t return glob;\n 9 \t}\n"
^done
(gdb)
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
I agree. I plan to remove the two backends (well, at least submit requests for) in 3 weeks from today. There are a lot of moving pieces right now and I'd really love for things to stabilize but also give people an opportunity to speak up, if they want to. -- Davide On Tue, Jan 30, 2018 at 5:30 AM, Tamas Berghammer wrote: > Originally I added the Java support to work with the Android ART runtime and > it has some pretty hard beaked in dependencies on the debug info ART > generates and on the version of ART available at that time (Android N) even > though I don't think this limitation is communicated clearly in source code > or in code reviews. Considering that AFAIK it haven't been tested with > Android O and haven't seen any bugfix for a while I would assume it is > mostly unused so I am happy to get it removed. And as Pavel said if somebody > want to use it again we can always add it back in with a better testing > strategy and long term plan. > > Generally for new language support I think we should have a similar policy > then what LLVM have for new backends. They should be developed out of tree > first without us providing a stable API (developer can fork a specific > version of LLDB, preferably upstream language independent bugfixes and then > pull in new changes once in a while) and if they are mature enough both in > terms of testing and maintenance commitment then they can be pulled into the > main LLDB source tree. > > Tamas > > On Tue, Jan 30, 2018 at 11:52 AM Pavel Labath via lldb-dev > wrote: >> >> Right, so, independently of this thread here, we've had an internal >> discussion about reviving java support. However, it is still very >> uncertain that this will actually happen , so I'm not opposed to >> removing it as we can always add it back later (with better testing, >> hopefully). >> >> Regardless of what happens here (and in light of the rust thread), I >> think a clearer bar for what we expect from new language support >> plugin would be useful for everyone. >> >> pl >> >> On 22 January 2018 at 20:13, Jim Ingham wrote: >> > To Davide's alternative: LLDB does handle loading plugins that use the >> > SB API's (for things like data formatters.) But there's not currently an >> > SB >> > interface to support >> > writing a full language plugin, and we don't export the lldb_private >> > API's from the lldb binary. So there's no current mechanism to provide >> > out-of-tree language plugins. It would be great to enable out-of-tree >> > language support mechanisms but we would have to design an SB interface for >> > that purpose. >> > >> > I see occasional questions about using Go with lldb on stack overflow >> > and the like. It might be good to put out a more general "anybody >> > interested in supporting this" call for Go, but I'm not sure the lldb-dev >> > list is the best place to find an owner. Is there some Go dev list we can >> > ask to see if anybody cares to support this? >> > >> > Non-stop never actually worked, it was just a promise, and the code for >> > it was pretty thin. I would be okay with pulling that out unless somebody >> > is actually getting good use out of it. >> > >> > Jim >> > >> >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev >> >> wrote: >> >> >> >> The Go support for added by Ryan as a 20% project. Now that he's no >> >> longer working for Google, it's pretty much abandoned. >> >> The Java support was added by us (android folks) to support java >> >> debugging (to a certain extent). However, we never really finished the >> >> project, so we're not using that code now. We're hoping to come back >> >> to it one day, but I agree we should not burden everyone else while we >> >> make up our mind on that. >> >> >> >> So I don't think anybody would shout at us if we removed them right >> >> now, but maybe we should make some effort to find a maintainer for >> >> them before removal? E.g. publicly declare that they are going to be >> >> deleted on date unless a maintainer steps up to take care of them >> >> (we can define the minimum level of support we'd expect from such a >> >> maintainer). Then I can e.g. forward the email to the Google Go folks >> >> and see if anyone of them wants to take that up. >> >> >> >> As for Java, I'm going to bring up the desire to remove the Java >> >> plugin on our team's meeting this week and get back to you with the >> >> result. >> >> >> >> >> >> In general I think that a clear deprecation/removal process would be >> >> nice to have. I have a couple of things I think are broken/unused >> >> (PlatformKalimba? non-stop mode?) but I haven't brought them up >> >> because I was unsure how to handle it. >> >> >> >> >> >> On 22 January 2018 at 15:28, Davide Italiano >> >> wrote: >> >>> Hi, >> >>> during my wandering I stumbled upon the `Go` and the `Java` plugins in >> >>> the lldb source tree. >> >>> They seem to not have been touched in a while, and I'm not necessarily >> >>> sure they're in a working state. Keeping the
