Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

On Mon, Jan 7, 2019 at 11:39 AM Adrian Prantl wrote: > > > On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano > wrote: > >> On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev >> wrote: >> > >> > O

Re: [lldb-dev] [cfe-dev] [llvm-dev] Updates on SVN to GitHub migration

(I wanted to ask about another update, but it looks like there was one posted to llvm-dev today: http://lists.llvm.org/pipermail/llvm-dev/2019-January/128840.html Mentioning this for others who subscribe to cfe-dev or similar but not llvm-dev.) On Mon, Dec 10, 2018 at 1:58 PM Nico Weber wrote: >

Re: [lldb-dev] [Reproducers] SBReproducer RFC

> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev > wrote: > > On 07/01/2019 19:26, Jonas Devlieghere wrote: >> On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > >> >> wrote: >>I've been thinking about how could t

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Mon, Jan 7, 2019 at 3:52 AM Tamas Berghammer wrote: > Thanks Pavel for looping me in. I haven't looked into the actual > implementation of the prototype yet but reading your description I have > some concern regarding the amount of data you capture as I feel it isn't > sufficient to reproduce

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > wrote: I've been thinking about how could this be done better, and the best (though not ideal) way I came up with is using the functions address as the key. That's gu

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath wrote: > On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: > > Hi Everyone, > > > > In September I sent out an RFC [1] about adding reproducers to LLDB. > > Over the > > past few months, I landed the reproducer framework, support for the GDB >

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

> On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev > wrote: > > On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano > wrote: > On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > > > On Fri, Jan 4, 2019 at 11:

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano wrote: > On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev > wrote: > > > > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss wrote: > >> > >> > >> > >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny > wrote: > >> > > >> > On Thu, Jan 3, 2019 at

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev wrote: > > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss wrote: >> >> >> >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny wrote: >> > >> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss wrote: >> > -llvm-dev + lldb-dev for the lldv test fai

Re: [lldb-dev] Unreliable process attach on Linux

* Pavel Labath: > Yes, there's a dns lookup being done on the other end. TBH, I'm not > really sure what's it being used for. Maybe we should try deleting the > hostname field from the qHostInfo response (or just put an IP address > there). Or use the system host name without resorting to DNS (us

Re: [lldb-dev] Accessing physical memory while remote debugging

Hi Daniel, Sanimir, This feature request is repeating every now and then :-). I think it's very useful, but it's not that easy to implement. Additional comments embedded. -- Zdenek Prikryl On 11/28/2018 07:01 PM, Sanimir Agovic via lldb-dev wrote: Hi Daniel, On Sat, Nov 24, 2018 at 9:34 P

Re: [lldb-dev] Unreliable process attach on Linux

On 07/01/2019 13:22, Florian Weimer wrote: * Pavel Labath: Thanks. I think this is what I suspected. The server is extremely slow in responding to the qHostInfo packet. This timeout for this was recently increased to 10 seconds, but it looks like 7.0 still has the default (1 second) timeout. I

Re: [lldb-dev] Unreliable process attach on Linux

* Pavel Labath: > Thanks. I think this is what I suspected. The server is extremely slow > in responding to the qHostInfo packet. This timeout for this was > recently increased to 10 seconds, but it looks like 7.0 still has the > default (1 second) timeout. > > If you don't want to recompile or up

Re: [lldb-dev] [Reproducers] SBReproducer RFC

Thanks Pavel for looping me in. I haven't looked into the actual implementation of the prototype yet but reading your description I have some concern regarding the amount of data you capture as I feel it isn't sufficient to reproduce a set of usecases. One problem is when the behavior of LLDB is n

Re: [lldb-dev] Unreliable process attach on Linux

On 07/01/2019 09:29, Florian Weimer wrote: * Pavel Labath: On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote: Consider this example program: #include #include #include #include #include #include int main(void) { // Target process for the debugger. pid_t pid = fork();

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: Hi Everyone, In September I sent out an RFC [1] about adding reproducers to LLDB. Over the past few months, I landed the reproducer framework, support for the GDB remote protocol and a bunch of preparatory changes. There's still an ope

Re: [lldb-dev] Unreliable process attach on Linux

* Pavel Labath: > On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote: >> Consider this example program: >> >> #include >> #include >> #include >> >> #include >> #include >> #include >> >> int >> main(void) >> { >>// Target process for the debugger. >>pid_t pid = fork(); >>if

Re: [lldb-dev] Unreliable process attach on Linux

On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote: Consider this example program: #include #include #include #include #include #include int main(void) { // Target process for the debugger. pid_t pid = fork(); if (pid < 0) err(1, "fork"); if (pid == 0) while (tr