Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)

2015-12-28 Thread Todd Fiala via lldb-dev 
Hi Andre,

On Sat, Dec 26, 2015 at 3:53 AM, Andre Vergison via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I tried Jason Molenda’s test code on El Capitan, lldb-340.4.119 (Jason
> Molenda via lldb-dev | 3 Oct 02:59 2015).
>
> I’m connected to a remote VM using ssh.
>
>
>
> tst$ echo 'int main () { }' > /tmp/a.c
>
> tst$ xcrun clang /tmp/a.c -o /tmp/a.out
>
> tst$ xcrun lldb /tmp/a.out
>
> (lldb) target create "/tmp/a.out"
>
> Current executable set to '/tmp/a.out' (x86_64).
>
> (lldb) r
>
> error: process exited with status -1 (unable to attach)
>
> (lldb) run
>
> error: process exited with status -1 (unable to attach)
>
> (lldb) quit
>
> tst$ ps -ef|grep a.out
>
>   502 33174 1   0 12:20PM ttys0000:00.00 /tmp/a.out
>
>   502 33187 1   0 12:20PM ttys0000:00.00 /tmp/a.out
>
>
Just shooting in the dark, but perhaps the a.out is either not in a state
where it can be touched (yet), could be zombified or something.  Have you
tried 'sudo kill -9' on them?  Also, if you look for a debugserver or lldb
in the process list (either of which could be a parent of it), are they
hanging around?  If so, killing them might allow the a.out processes to die.

Are you using an lldb that you built?  If so, the underlying attach problem
could be due to some kind signing/permissions with debugserver.  To have
lldb use the official Xcode version of lldb's debugserver (assuming you
have Xcode installed and aren't trying to use just the command line tools),
you should be able to build with a command line like this:

xcodebuild -scheme desktop -configuration Debug
DEBUGSERVER_USE_FROM_SYSTEM=1

Or from within Xcode itself, locally adjust your Xcode project to set the
"DEBUGSERVER_USE_FROM_SYSTEM" user variable to 1.

I'm not sure if you already did this, but you may need to turn on your dev
tools security via:
sudo DevToolSecurity --enable

Let us know if that gets you any further.

Thanks!

-Todd


>
> I can’t even kill those using kill -9.
>
>
>
> What’s going on here?
>
>
>
> I tried the above because in fact I had a process which a segmentation
> fault 11, here’s what lldb makes out of the core dump:
>
>
>
> txt$ lldb /cores/core.33158
>
> (lldb) target create "/cores/core.33158"
>
> warning: (x86_64) /cores/core.33158 load command 175 LC_SEGMENT_64 has a
> fileoff
>
>  + filesize (0x31c57000) that extends beyond the end of the file
> (0x31c56000), t
>
> he segment will be truncated to match
>
> warning: (x86_64) /cores/core.33158 load command 176 LC_SEGMENT_64 has a
> fileoff
>
>  (0x31c57000) that extends beyond the end of the file (0x31c56000),
> ignoring thi
>
> s section
>
> Current executable set to '/cores/core.33158' (x86_64).
>
> (lldb)
>
>
>
> Is this related? Compiled with g++ :
>
>
>
> tst$ g++ --version
>
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
> --with-gxx-inc
>
> lude-dir=/usr/include/c++/4.2.1
>
> Apple LLVM version 7.0.2 (clang-700.1.81)
>
> Target: x86_64-apple-darwin15.0.0
>
> Thread model: posix
>
>
>
> Thx,
>
> Andre
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

2015-12-28 Thread Todd Fiala via lldb-dev 
Hi William,

It looks like just the PRIx64/PRIu64 bits are needed from a visual
inspection.  The source variables that are printed from already are 64-bit
always, aren't they?  If they're not but they should be, that seems like
the real underlying problem rather than needing to cast.

What kind of warning are you seeing if you just replace the % format
specifier?

Thanks!

-Todd

On Sun, Dec 27, 2015 at 12:32 PM, William Dillon via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> > Message: 1
> > Date: Sat, 26 Dec 2015 21:15:53 +0100
> > From: Joerg Sonnenberger via lldb-dev 
> > To: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] Patch for addressing format warnings on 32-bit
> > Message-ID: <20151226201553.gb14...@britannica.bec.de>
> > Content-Type: text/plain; charset=utf-8
> >
> > On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev
> wrote:
> >> There are a handful of -Wformat warnings on 32-bit platforms.
> >> I addressed all those that I’ve seen while working on Swift.
> >> Let me know if the git diff format is inappropriate for this.
> >
> > Don't cast size_t to uint64_t, format it with %zu directly.
> >
> > Joerg
> >
>
> I can go ahead and do that, but I wonder whether there should be two
> different ways of handling this, even on the same line.  For example:
>
> -error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
> addr=0x%" PRIx64 ": tried to read %lu bytes but only read %" PRIu64,
> __FUNCTION__, m_addr, m_opcode_size, (uint64_t)bytes_read);
> +error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
> addr=0x%" PRIx64 ": tried to read %" PRIu64 " bytes but only read %"
> PRIu64, __FUNCTION__, m_addr, (uint64_t)m_opcode_size,
> (uint64_t)bytes_read);
>
> - Will
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

2015-12-28 Thread William Dillon via lldb-dev 
Hi Todd,

The example I put in my last email is one of a few (maybe one more) instances 
where the existing code casts to 64-bit and uses PRIu64.  When I’m dabbling in 
existing code I try to copy the conventions that are already in place, so 
that’s why I went this way.  I’m happy to change it to %zu.  I was just 
checking about that.

- Will

> On Dec 28, 2015, at 10:24 AM, Todd Fiala  wrote:
> 
> Hi William,
> 
> It looks like just the PRIx64/PRIu64 bits are needed from a visual 
> inspection.  The source variables that are printed from already are 64-bit 
> always, aren't they?  If they're not but they should be, that seems like the 
> real underlying problem rather than needing to cast.
> 
> What kind of warning are you seeing if you just replace the % format 
> specifier?
> 
> Thanks!
> 
> -Todd
> 
> On Sun, Dec 27, 2015 at 12:32 PM, William Dillon via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> > Message: 1
> > Date: Sat, 26 Dec 2015 21:15:53 +0100
> > From: Joerg Sonnenberger via lldb-dev  > >
> > To: lldb-dev@lists.llvm.org 
> > Subject: Re: [lldb-dev] Patch for addressing format warnings on 32-bit
> > Message-ID: <20151226201553.gb14...@britannica.bec.de 
> > >
> > Content-Type: text/plain; charset=utf-8
> >
> > On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev wrote:
> >> There are a handful of -Wformat warnings on 32-bit platforms.
> >> I addressed all those that I’ve seen while working on Swift.
> >> Let me know if the git diff format is inappropriate for this.
> >
> > Don't cast size_t to uint64_t, format it with %zu directly.
> >
> > Joerg
> >
> 
> I can go ahead and do that, but I wonder whether there should be two 
> different ways of handling this, even on the same line.  For example:
> 
> -error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s 
> addr=0x%" PRIx64 ": tried to read %lu bytes but only read %" PRIu64, 
> __FUNCTION__, m_addr, m_opcode_size, (uint64_t)bytes_read);
> +error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s 
> addr=0x%" PRIx64 ": tried to read %" PRIu64 " bytes but only read %" PRIu64, 
> __FUNCTION__, m_addr, (uint64_t)m_opcode_size, (uint64_t)bytes_read);
> 
> - Will
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> 
> 
> 
> -- 
> -Todd

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev