Re: [lldb-dev] Patch for addressing format warnings on 32-bit
I believe %z will not work on MSVC 2013, which we are still using on windows.
pl
On 28 December 2015 at 18:32, William Dillon via lldb-dev
wrote:
> 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
> 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] Schedule and call for testers
Sounds good. On 11 December 2015 at 23:14, Hans Wennborg wrote: > Dear everyone, > > It's not quite time to start the 3.8 release process, but it's time to > start planning. > > Please let me know if you want to help with testing and building > release binaries for your favourite platform. (If you were a tester on > the previous release, you're cc'd on this email.) > > I propose the following schedule for the 3.8 release: > > - 13 January: Create 3.8 branch. Testing Phase 1: RC1 binaries built > and tested, bugs fixed. Any almost-complete features need to be > wrapped up or disabled on the branch ASAP, and definitely before this > phase ends. > > - 27 January: Testing Phase 2: RC2 binaries built and tested. Only > critical bug fixes from now on. Further RCs published as we approach.. > > - 18 February: Cut the final release, build binaries, ship when ready. > > Unless there are any objections, I'll post this on the web page. > > Cheers, > Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26010] New: LLDB fails to display content of a variable size array
https://llvm.org/bugs/show_bug.cgi?id=26010
Bug ID: 26010
Summary: LLDB fails to display content of a variable size array
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Compile the following code snippet with g++ (tested with 4.8.2 on Linux
x86_64):
int main() {
for (int i = 0; i < 10; ++i) {
int x[i + 1];
x[0] = sizeof(x);
x[0] *= 2; // Break here
}
}
Break at the marked line and display the variable x with executing the "frame
variable x" command.
Expected behavior is to display x as an array with the number of displayed
elements matching with the actual element count of the array in the current
implementation.
Actual behavior is that the array is always displayed with 4 element regardless
of the current iteration.
In the same scenario gdb displays the array with the correct number of element.
If the inferior is compiled with clang then gdb fails as well because incorrect
debug info is generated (http://llvm.org/pr25934)
The problem is that for variable sized arrays g++ correctly generates a
DW_TAG_subrange_type children with a DW_AT_upper_bound attribute containing a
dwarf expression pointing to the location where the current size of the array
is stored but LLDB don't handle the case where DW_AT_upper_bound is a dwarf
expression.
--
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] LLVM Social - Paris: January 27th, 2016
The next LLVM social in Paris will happen on January 27th, 2016. Everyone interested in LLVM, Clang, lldb, Polly, ... is invited to join. For this meetup, we will start with John Regehr giving us a talk about undefined behaviour and we will continue with our usual casual meeting. Event details, including free registration at http://www.meetup.com/LLVM-Clang-social Looking forward to meet you, -- Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)
If you ssh in you must enable developer mode one time per boot:
sudo /usr/sbin/DevToolsSecurity --enable
Then you should be able to debug. If you don't, it will popup a dialog box on
the remote system that attempts to get authorization, but you will never see
that in your SSH window...
Let me know if this helps.
Greg
> On Dec 26, 2015, at 3:53 AM, Andre Vergison via lldb-dev
> 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
>
> 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
___
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
Please do cast to 64 bit and user PRI*64 macros. %z isn't supported on all
platforms and we need to get away from using it.
> On Dec 28, 2015, at 10:32 AM, William Dillon via lldb-dev
> wrote:
>
> 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
>> 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
___
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
Incidentally, once we can start requiring VS 2015 %z will be supported
there. Not sure if MSVC is the only supported platform that currently
doesn't support %z
On Mon, Jan 4, 2016 at 11:24 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Please do cast to 64 bit and user PRI*64 macros. %z isn't supported on all
> platforms and we need to get away from using it.
>
> > On Dec 28, 2015, at 10:32 AM, William Dillon via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > 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 <
> 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
>
> ___
> 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
