date:20161017

[lldb-dev] GitHub Survey Online

2016-10-17 Thread Renato Golin via lldb-dev

Folks,

After a number of months in preparation and just two weeks away from
the US Dev. Meeting, where we'll hold a BoF to discuss the Git
migration, here's how you'll voice your concerns:

https://goo.gl/forms/ZYs0Wv9g0w0ikCRQ2

The survey is meant to be a channel for people and
companies/projects/universities to voice their concerns as well as
describe their workflow if anything proposed will seriously disrupt
the work of LLVM developers.

The multiple-choice questions will also be used to gauge the general
feeling of the community, but it will not be considered a vote. No
decision will be taken on those numbers alone, so please, make sure to
describe your issues on the text boxes provided.

The last thing we want is to make less people contribute to the
project. And that's one of the reasons we're proposing to move to Git,
because the majority of people already use it, here or elsewhere. It
has been pointed out that all fresh developers nowadays use Git
natively, partly because of the success of projects like GitHub.

But that means the move has to be in a way that the majority of
developers today, and future developers too, can easily work with.

Please, share the word, and let's make sure that two weeks is enough
to cover everyone in our community, so that we can have a meaningful
and trouble-free discussion at the Dev. Meeting.

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

Re: [lldb-dev] add custom vendor commands

2016-10-17 Thread Greg Clayton via lldb-dev


> On Oct 13, 2016, at 2:24 AM, Giusti, Valentina via lldb-dev 
>  wrote:
> 
> Hello all,
> 
> Background: 
> Intel CPUs that support MPX have a limited number of bound registers. For any 
> program that has more objects than fit into these registers, the bounds must 
> be kept elsewhere. For this purpose, Bounds Tables (BT) are stored in 
> application memory: for each pointer there is a bound table entry with lower 
> bound, upper bound, check pointer value.
> 
> It would be convenient for the user to be able to access the BT and possibly 
> also manipulate it, through commands like: 'set/show mpx-bounds 
>   '.
> 
> Is there a way to add customized commands for vendor features, such as this 
> one?
> I have seen that CommandObjectCommands has a class to add commands 
> interpreted by command interpreter scripts and an interface for command 
> aliases, so I wonder if it would make sense to add something else for vendor 
> commands. For example, I could create a new class CommandObjectVendor that 
> allows vendors to create their own specific commands. In my case, for the MPX 
> bound table, the commands could be:
>   
>   intel show mpx-bounds   
> 
>   intel set mpx-bounds
> 
> 
> Thanks in advance for your help,
> 

You can install new python commands that can do the job to work out the 
details. 

http://lldb.llvm.org/python-reference.html

See the section named "CREATE A NEW LLDB COMMAND USING A PYTHON FUNCTION".

You can basically install a new "intel" command and parse all of the options 
"show mpx-bounds ..." or "set mpx-bounds ..." from within this new command. You 
can use the public LLDB API to look through the process and do things. Let me 
know if you need any help with this. There is also a API to add custom commands 
from C++ plug-ins. Enrico Granata did this work and can answer more questions 
on that. Either way, both commands (python and C++ plug-ins) have access to the 
public API for LLDB, so the code you will write will use the same API. So I 
would stick with python for now to get things working.

Some questions for you:
- How do plan on detecting that you have an intel processor? 
- Do you need access to any process registers? If so, are these registers 
thread specific? Are these registers available currently on linux and MacOS?
- How do you locate the BT? (or do you even need to?). Is there symbol? Can you 
extract all values in the bounds table once you locate it?

Let me know if you have any questions,

Greg Clayton

> - V.
> 
> 
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> ___
> 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] unaligned cast in TCPSocket::Connect

2016-10-17 Thread Greg Clayton via lldb-dev

> On Oct 13, 2016, at 10:52 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> TCPSocket::Connect has this line:
> host_str = ::inet_ntoa (*(struct in_addr 
> *)*host_entry->h_addr_list);
>  
> host_entry->h_addr_list is a char**, while struct in_addr contains a 
> uint32_t. Casting like this (char * to uint_32t *) could cause a bus error on 
> systems that don’t allow non-aligned loads. I think we need to memcpy the 
> data into a struct in_addr variable.
>  
> Anyone have any thoughts on this?

You will have to memcpy into a local that will be correctly aligned before you 
play with it. Or you can use DataExtractor as it already does the right thing. 
We ran into similar issues with DWARF parsing on systems that don't allow 
non-aligned loads, so DataExtractor can extract data correctly no matter what 
the alignment.

Greg

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

Re: [lldb-dev] LLDB can't find source...but it can?

2016-10-17 Thread Greg Clayton via lldb-dev

This is a compiler bug. 

> On Oct 14, 2016, at 12:14 PM, Ted Woodward  
> wrote:
> 
>> Probably a debug info problem. Before we know to look for addresses within
>> a compile unit, the compile unit must claim it has a function that contains 
>> this
>> address. So check the DWARF in the compile unit that contains 0x114720 (not
>> sure if there is a lookup by address in llmv-dwarfdump?) and make sure
>> there is a DW_TAG_subprogram that contains this address.
>> 
>> Greg
> 
> I'm changing gears here - I'm having the same issue with lldb-server, and 
> it's smaller, so I'm looking at that.
> 
> main calls main_gdbserver, which is in tools/lldb-server/lldb-gdbserver.cpp, 
> and has no line table info, according to lldb's list comm info.
> 
> 4: name = 'main_gdbserver', locations = 2
>  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
> 0x00048964, unresolved, hit count = 0
>  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
> 0x00048964, unresolved, hit count = 0
> 
> (lldb) list 0x48964
> error: address resolves to lldb-server[0x00048964], but there is no 
> line table information available for this address.
> 
> 
> main_gdbserver has a DW_AT_subprogram entry:
> 0x000306a4:   DW_TAG_subprogram [106] *
>DW_AT_low_pc [DW_FORM_addr](0x00048944)
>DW_AT_high_pc [DW_FORM_data4]  (0x0da4)
>DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 6e )
>DW_AT_linkage_name [DW_FORM_strp]  ( 
> .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
>DW_AT_name [DW_FORM_strp]  ( .debug_str[0x00065792] = 
> "main_gdbserver")
>DW_AT_decl_file [DW_FORM_data1]
> ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-server/lldb-gdbserver.cpp")
>DW_AT_decl_line [DW_FORM_data2](326)
>DW_AT_type [DW_FORM_ref4]  (cu + 0x003b => {0x00011c13})
>DW_AT_external [DW_FORM_flag_present]  (true)
> 
> And a linetable entry:
> 0x00048944327  0  1   0 0  is_stmt
> 0x0004896432811  1   0 0  is_stmt prologue_end
> 
> 
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Tuesday, October 11, 2016 1:34 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
>> 
>> 
>>> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev > d...@lists.llvm.org> wrote:
>>> 
>>> Background – I’m working on getting LLDB to run on Hexagon Linux, built
>> with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a bit
>> squirrelly right now, so I’ve built LLDB statically.
>>> 
>>> I’ve got full source debugging in the driver, but when I step into
>> SBDebugger::Create, I don’t have any source. I’ve got symbols:
>>> (lldb) bt
>>> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16,
>> stop reason = breakpoint 2.1
>>>  * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
>>>frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124 at
>> Driver.cpp:150
>>>frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
>> Driver.cpp:1350
>>>frame #3: 0x04744384 lldb`__libc_start_main + 48
>>> 
>>> list SBDebugger::Create fails, but list SBDebugger::Create(bool) gives me
>> source.
>>> (lldb) list SBDebugger::Create
>>> (lldb) list SBDebugger::Create(bool)
>>> File:
>> \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.cp
>> p
>>>   172  return SBDebugger::Create(false, nullptr, nullptr);
>>>   173  }
>>>   174
>>>   175  SBDebugger
>>>   176  SBDebugger::Create(bool source_init_files)
>>>   177  {
>>>   178  return SBDebugger::Create (source_init_files, nullptr, nullptr);
>>>   179  }
>>>   180
>>>   181  SBDebugger
>>>   182  SBDebugger::Create(bool source_init_files, lldb::LogOutputCallback
>> callback, void *baton)
>>>   183
>>> 
>>> Finally, I try to list based on the address of the function:
>>> (lldb) list 0x114720
>>> error: address resolves to lldb[0x00114720], but there is no line
>> table information available for this address.
>>> 
>>> But there is line table information for 0x114720 (from llvm-dwarfdump):
>>> 0x00114720177  0 80   0 0  is_stmt
>>> 0x00114730178 32 80   0 0  is_stmt 
>>> prologue_end
>>> 0x00114734178 12 80   0 0
>>> 0x00114754178  5 80   0 0
>>> 
>>> 
>>> 
>>> My breakpoint at SBDebugger::Create resolved to prologue_end:
>>> (lldb) break list
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 1
>>>  1.1: where = lldb`main + 32 at Driver.cpp:1335, address =

Re: [lldb-dev] LLDB can't find source...but it can?

2016-10-17 Thread Ted Woodward via lldb-dev

What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, and 
linetable entries for the addresses of main_gdbserver. 

I've found that getting DWARF compiler bugs fixed can be...challenging. The 
better I can narrow it down for the compiler engineers, the better. 

This is clang that was ToT about 2 months ago, BTW.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Monday, October 17, 2016 11:03 AM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> 
> This is a compiler bug.
> 
> > On Oct 14, 2016, at 12:14 PM, Ted Woodward
>  wrote:
> >
> >> Probably a debug info problem. Before we know to look for addresses
> >> within a compile unit, the compile unit must claim it has a function
> >> that contains this address. So check the DWARF in the compile unit
> >> that contains 0x114720 (not sure if there is a lookup by address in
> >> llmv-dwarfdump?) and make sure there is a DW_TAG_subprogram that
> contains this address.
> >>
> >> Greg
> >
> > I'm changing gears here - I'm having the same issue with lldb-server, and
> it's smaller, so I'm looking at that.
> >
> > main calls main_gdbserver, which is in tools/lldb-server/lldb-
> gdbserver.cpp, and has no line table info, according to lldb's list comm info.
> >
> > 4: name = 'main_gdbserver', locations = 2
> >  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >
> > (lldb) list 0x48964
> > error: address resolves to lldb-server[0x00048964], but there is no
> line table information available for this address.
> >
> >
> > main_gdbserver has a DW_AT_subprogram entry:
> > 0x000306a4:   DW_TAG_subprogram [106] *
> >DW_AT_low_pc [DW_FORM_addr]  (0x00048944)
> >DW_AT_high_pc [DW_FORM_data4](0x0da4)
> >DW_AT_frame_base [DW_FORM_exprloc]   (<0x1> 6e )
> >DW_AT_linkage_name [DW_FORM_strp](
> .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
> >DW_AT_name [DW_FORM_strp]( .debug_str[0x00065792] =
> "main_gdbserver")
> >DW_AT_decl_file [DW_FORM_data1]
>   ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-
> server/lldb-gdbserver.cpp")
> >DW_AT_decl_line [DW_FORM_data2]  (326)
> >DW_AT_type [DW_FORM_ref4](cu + 0x003b => {0x00011c13})
> >DW_AT_external [DW_FORM_flag_present](true)
> >
> > And a linetable entry:
> > 0x00048944327  0  1   0 0  is_stmt
> > 0x0004896432811  1   0 0  is_stmt 
> > prologue_end
> >
> >
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >> -Original Message-
> >> From: Greg Clayton [mailto:gclay...@apple.com]
> >> Sent: Tuesday, October 11, 2016 1:34 PM
> >> To: Ted Woodward 
> >> Cc: LLDB 
> >> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> >>
> >>
> >>> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Background – I’m working on getting LLDB to run on Hexagon Linux,
> >>> built
> >> with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a
> >> bit squirrelly right now, so I’ve built LLDB statically.
> >>>
> >>> I’ve got full source debugging in the driver, but when I step into
> >> SBDebugger::Create, I don’t have any source. I’ve got symbols:
> >>> (lldb) bt
> >>> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool)
> >>> + 16,
> >> stop reason = breakpoint 2.1
> >>>  * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
> >>>frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124
> >>> at
> >> Driver.cpp:150
> >>>frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
> >> Driver.cpp:1350
> >>>frame #3: 0x04744384 lldb`__libc_start_main + 48
> >>>
> >>> list SBDebugger::Create fails, but list SBDebugger::Create(bool)
> >>> gives me
> >> source.
> >>> (lldb) list SBDebugger::Create
> >>> (lldb) list SBDebugger::Create(bool)
> >>> File:
> >>
> \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.
> >> cp
> >> p
> >>>   172  return SBDebugger::Create(false, nullptr, nullptr);
> >>>   173  }
> >>>   174
> >>>   175  SBDebugger
> >>>   176  SBDebugger::Create(bool source_init_files)
> >>>   177  {
> >>>   178  return SBDebugger::Create (source_init_files, nullptr, 
> >>> nullptr);
> >>>   179  }
> >>>   180
> >>>   181  SBDebugger
> >>>   182  SBDebugger::Create(bool source_init

Re: [lldb-dev] LLDB can't find source...but it can?

2016-10-17 Thread Greg Clayton via lldb-dev

Send me the file offline. I will help narrow it down for you.

> On Oct 17, 2016, at 9:58 AM, Ted Woodward  wrote:
> 
> What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, 
> and linetable entries for the addresses of main_gdbserver. 
> 
> I've found that getting DWARF compiler bugs fixed can be...challenging. The 
> better I can narrow it down for the compiler engineers, the better. 
> 
> This is clang that was ToT about 2 months ago, BTW.
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Monday, October 17, 2016 11:03 AM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
>> 
>> This is a compiler bug.
>> 
>>> On Oct 14, 2016, at 12:14 PM, Ted Woodward
>>  wrote:
>>> 
 Probably a debug info problem. Before we know to look for addresses
 within a compile unit, the compile unit must claim it has a function
 that contains this address. So check the DWARF in the compile unit
 that contains 0x114720 (not sure if there is a lookup by address in
 llmv-dwarfdump?) and make sure there is a DW_TAG_subprogram that
>> contains this address.
 
 Greg
>>> 
>>> I'm changing gears here - I'm having the same issue with lldb-server, and
>> it's smaller, so I'm looking at that.
>>> 
>>> main calls main_gdbserver, which is in tools/lldb-server/lldb-
>> gdbserver.cpp, and has no line table info, according to lldb's list comm 
>> info.
>>> 
>>> 4: name = 'main_gdbserver', locations = 2
>>> 4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address =
>>> 0x00048964, unresolved, hit count = 0
>>> 4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address =
>>> 0x00048964, unresolved, hit count = 0
>>> 
>>> (lldb) list 0x48964
>>> error: address resolves to lldb-server[0x00048964], but there is no
>> line table information available for this address.
>>> 
>>> 
>>> main_gdbserver has a DW_AT_subprogram entry:
>>> 0x000306a4:   DW_TAG_subprogram [106] *
>>>   DW_AT_low_pc [DW_FORM_addr]   (0x00048944)
>>>   DW_AT_high_pc [DW_FORM_data4] (0x0da4)
>>>   DW_AT_frame_base [DW_FORM_exprloc](<0x1> 6e )
>>>   DW_AT_linkage_name [DW_FORM_strp] (
>> .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
>>>   DW_AT_name [DW_FORM_strp] ( .debug_str[0x00065792] =
>> "main_gdbserver")
>>>   DW_AT_decl_file [DW_FORM_data1]
>>  ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-
>> server/lldb-gdbserver.cpp")
>>>   DW_AT_decl_line [DW_FORM_data2]   (326)
>>>   DW_AT_type [DW_FORM_ref4] (cu + 0x003b => {0x00011c13})
>>>   DW_AT_external [DW_FORM_flag_present] (true)
>>> 
>>> And a linetable entry:
>>> 0x00048944327  0  1   0 0  is_stmt
>>> 0x0004896432811  1   0 0  is_stmt 
>>> prologue_end
>>> 
>>> 
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>> 
 -Original Message-
 From: Greg Clayton [mailto:gclay...@apple.com]
 Sent: Tuesday, October 11, 2016 1:34 PM
 To: Ted Woodward 
 Cc: LLDB 
 Subject: Re: [lldb-dev] LLDB can't find source...but it can?
 
 
> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev >>> d...@lists.llvm.org> wrote:
> 
> Background – I’m working on getting LLDB to run on Hexagon Linux,
> built
 with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a
 bit squirrelly right now, so I’ve built LLDB statically.
> 
> I’ve got full source debugging in the driver, but when I step into
 SBDebugger::Create, I don’t have any source. I’ve got symbols:
> (lldb) bt
> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool)
> + 16,
 stop reason = breakpoint 2.1
> * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
>   frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124
> at
 Driver.cpp:150
>   frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
 Driver.cpp:1350
>   frame #3: 0x04744384 lldb`__libc_start_main + 48
> 
> list SBDebugger::Create fails, but list SBDebugger::Create(bool)
> gives me
 source.
> (lldb) list SBDebugger::Create
> (lldb) list SBDebugger::Create(bool)
> File:
 
>> \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.
 cp
 p
>  172  return SBDebugger::Create(false, nullptr, nullptr);
>  173  }
>  174
>  175  SBDebugger
>  176  SBDebugger::Create(bool source_init_files)
>  177  {
>  178  return SBDebug

[lldb-dev] File::Read does not read everything

2016-10-17 Thread Eugene Birukov via lldb-dev

Hello,


I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is located 
on Windows file share mounted on Linux via mount.cifs. I see that we 
successfully allocated memory and are trying to fill it in one read. 
Unfortunately pread returns 2GiB and we never check for short read here.


I think we could combine this code with previous block "#if defined 
(MAX_READ_SIZE)" if we simply check for short read here (bytes_read too small) 
and loop until all the buffer is filled.


Thanks,

Eugene


#ifndef _WIN32
int fd = GetDescriptor();
if (fd != kInvalidDescriptor)
{
ssize_t bytes_read = -1;
do
{
bytes_read = ::pread (fd, buf, num_bytes, offset);
} while (bytes_read < 0 && errno == EINTR);

if (bytes_read < 0)
{
num_bytes = 0;
error.SetErrorToErrno();
}
else
{
offset += bytes_read;
num_bytes = bytes_read;
}
}


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

Re: [lldb-dev] File::Read does not read everything

2016-10-17 Thread Greg Clayton via lldb-dev

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hello,
> 
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
> 
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
> 
> Thanks,
> Eugene
> 
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
> 
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
> 
> Sent from Outlook
> ___
> 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] File::Read does not read everything

2016-10-17 Thread Eugene Birukov via lldb-dev

Here is what I am running now:


diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
index 89587a9..a4ac25e 100644
--- a/source/Host/common/File.cpp
+++ b/source/Host/common/File.cpp
@@ -771,21 +771,34 @@ File::Read (void *buf, size_t &num_bytes, off_t &offset)
 int fd = GetDescriptor();
 if (fd != kInvalidDescriptor)
 {
-ssize_t bytes_read = -1;
-do
+size_t bytes_left = num_bytes;
+num_bytes = 0;
+char *pos = (char*)buf;
+while (bytes_left > 0)
 {
-bytes_read = ::pread (fd, buf, num_bytes, offset);
-} while (bytes_read < 0 && errno == EINTR);
+ssize_t bytes_read = -1;
+do
+{
+bytes_read = ::pread (fd, pos, bytes_left, offset);
+} while (bytes_read < 0 && errno == EINTR);

-if (bytes_read < 0)
-{
-num_bytes = 0;
-error.SetErrorToErrno();
-}
-else
-{
-offset += bytes_read;
-num_bytes = bytes_read;
+if (bytes_read < 0)
+{
+num_bytes = 0;
+error.SetErrorToErrno();
+break;
+}
+else if (bytes_read == 0)
+{
+break;
+}
+else
+{
+offset += bytes_read;
+num_bytes += bytes_read;
+bytes_left -= bytes_read;
+pos += bytes_read;
+}
 }
 }
 else




Sent from Outlook



From: Greg Clayton 
Sent: Monday, October 17, 2016 12:39 PM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
>  wrote:
>
> Hello,
>
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
>
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
>
> Thanks,
> Eugene
>
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
>
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
>
> Sent from Outlook
> ___
> 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] File::Read does not read everything

2016-10-17 Thread Zachary Turner via lldb-dev

Can you upload a diff (with context) to phabricator and add lldb-commits as
a subscriber and myself / Greg as reviewers?

On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Here is what I am running now:
>
>
> diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
> index 89587a9..a4ac25e 100644
> --- a/source/Host/common/File.cpp
> +++ b/source/Host/common/File.cpp
> @@ -771,21 +771,34 @@ File::Read (void *buf, size_t &num_bytes, off_t
> &offset)
>  int fd = GetDescriptor();
>  if (fd != kInvalidDescriptor)
>  {
> -ssize_t bytes_read = -1;
> -do
> +size_t bytes_left = num_bytes;
> +num_bytes = 0;
> +char *pos = (char*)buf;
> +while (bytes_left > 0)
>  {
> -bytes_read = ::pread (fd, buf, num_bytes, offset);
> -} while (bytes_read < 0 && errno == EINTR);
> +ssize_t bytes_read = -1;
> +do
> +{
> +bytes_read = ::pread (fd, pos, bytes_left, offset);
> +} while (bytes_read < 0 && errno == EINTR);
>
> -if (bytes_read < 0)
> -{
> -num_bytes = 0;
> -error.SetErrorToErrno();
> -}
> -else
> -{
> -offset += bytes_read;
> -num_bytes = bytes_read;
> +if (bytes_read < 0)
> +{
> +num_bytes = 0;
> +error.SetErrorToErrno();
> +break;
> +}
> +else if (bytes_read == 0)
> +{
> +break;
> +}
> +else
> +{
> +offset += bytes_read;
> +num_bytes += bytes_read;
> +bytes_left -= bytes_read;
> +pos += bytes_read;
> +}
>  }
>  }
>  else
>
>
>
> Sent from Outlook 
>
>
> --
> *From:* Greg Clayton 
> *Sent:* Monday, October 17, 2016 12:39 PM
> *To:* Eugene Birukov
> *Cc:* LLDB
> *Subject:* Re: [lldb-dev] File::Read does not read everything
>
> It is probably best to make the code loop as long as "bytes_reads > 0" and
> we haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read
> size which gets set to MAX_READ_SIZE, but we need to do that because if you
> try to read more than that it reads nothing. So MAX_READ_SIZE is more for
> the case where the read will outright fail if given a byte size that is too
> large. Feel free to submit a patch that can keep calling pread correctly in
> a loop as long as bytes_read > 0.
>
> Greg
>
> > On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >
> > I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is
> located on Windows file share mounted on Linux via mount.cifs. I see that
> we successfully allocated memory and are trying to fill it in one read.
> Unfortunately pread returns 2GiB and we never check for short read here.
> >
> > I think we could combine this code with previous block "#if defined
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too
> small) and loop until all the buffer is filled.
> >
> > Thanks,
> > Eugene
> >
> > #ifndef _WIN32
> > int fd = GetDescriptor();
> > if (fd != kInvalidDescriptor)
> > {
> > ssize_t bytes_read = -1;
> > do
> > {
> > bytes_read = ::pread (fd, buf, num_bytes, offset);
> > } while (bytes_read < 0 && errno == EINTR);
> >
> > if (bytes_read < 0)
> > {
> > num_bytes = 0;
> > error.SetErrorToErrno();
> > }
> > else
> > {
> > offset += bytes_read;
> > num_bytes = bytes_read;
> > }
> > }
> >
> > Sent from Outlook
> > ___
> > 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

Re: [lldb-dev] File::Read does not read everything

2016-10-17 Thread Eugene Birukov via lldb-dev

Sorry for noob's question: what is "phabricator"?

Sure, I will do it as soon as I understand what you want me to do :)


Sent from Outlook



From: Zachary Turner 
Sent: Monday, October 17, 2016 5:01 PM
To: Eugene Birukov; Greg Clayton
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

Can you upload a diff (with context) to phabricator and add lldb-commits as a 
subscriber and myself / Greg as reviewers?

On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Here is what I am running now:


diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
index 89587a9..a4ac25e 100644
--- a/source/Host/common/File.cpp
+++ b/source/Host/common/File.cpp
@@ -771,21 +771,34 @@ File::Read (void *buf, size_t &num_bytes, off_t &offset)
 int fd = GetDescriptor();
 if (fd != kInvalidDescriptor)
 {
-ssize_t bytes_read = -1;
-do
+size_t bytes_left = num_bytes;
+num_bytes = 0;
+char *pos = (char*)buf;
+while (bytes_left > 0)
 {
-bytes_read = ::pread (fd, buf, num_bytes, offset);
-} while (bytes_read < 0 && errno == EINTR);
+ssize_t bytes_read = -1;
+do
+{
+bytes_read = ::pread (fd, pos, bytes_left, offset);
+} while (bytes_read < 0 && errno == EINTR);

-if (bytes_read < 0)
-{
-num_bytes = 0;
-error.SetErrorToErrno();
-}
-else
-{
-offset += bytes_read;
-num_bytes = bytes_read;
+if (bytes_read < 0)
+{
+num_bytes = 0;
+error.SetErrorToErrno();
+break;
+}
+else if (bytes_read == 0)
+{
+break;
+}
+else
+{
+offset += bytes_read;
+num_bytes += bytes_read;
+bytes_left -= bytes_read;
+pos += bytes_read;
+}
 }
 }
 else




Sent from Outlook



From: Greg Clayton mailto:gclay...@apple.com>>
Sent: Monday, October 17, 2016 12:39 PM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
> Hello,
>
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
>
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
>
> Thanks,
> Eugene
>
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
>
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
>
> Sent from Outlook
> ___
> 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

Re: [lldb-dev] File::Read does not read everything

2016-10-17 Thread Zachary Turner via lldb-dev

http://reviews.llvm.org. Create an account there and upload patch
On Mon, Oct 17, 2016 at 5:15 PM Eugene Birukov  wrote:

> Sorry for noob's question: what is "phabricator"?
>
> Sure, I will do it as soon as I understand what you want me to do :)
>
>
> Sent from Outlook 
>
>
> --
> *From:* Zachary Turner 
> *Sent:* Monday, October 17, 2016 5:01 PM
> *To:* Eugene Birukov; Greg Clayton
>
> *Cc:* LLDB
> *Subject:* Re: [lldb-dev] File::Read does not read everything
> Can you upload a diff (with context) to phabricator and add lldb-commits
> as a subscriber and myself / Greg as reviewers?
>
> On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Here is what I am running now:
>
>
> diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
> index 89587a9..a4ac25e 100644
> --- a/source/Host/common/File.cpp
> +++ b/source/Host/common/File.cpp
> @@ -771,21 +771,34 @@ File::Read (void *buf, size_t &num_bytes, off_t
> &offset)
>  int fd = GetDescriptor();
>  if (fd != kInvalidDescriptor)
>  {
> -ssize_t bytes_read = -1;
> -do
> +size_t bytes_left = num_bytes;
> +num_bytes = 0;
> +char *pos = (char*)buf;
> +while (bytes_left > 0)
>  {
> -bytes_read = ::pread (fd, buf, num_bytes, offset);
> -} while (bytes_read < 0 && errno == EINTR);
> +ssize_t bytes_read = -1;
> +do
> +{
> +bytes_read = ::pread (fd, pos, bytes_left, offset);
> +} while (bytes_read < 0 && errno == EINTR);
>
> -if (bytes_read < 0)
> -{
> -num_bytes = 0;
> -error.SetErrorToErrno();
> -}
> -else
> -{
> -offset += bytes_read;
> -num_bytes = bytes_read;
> +if (bytes_read < 0)
> +{
> +num_bytes = 0;
> +error.SetErrorToErrno();
> +break;
> +}
> +else if (bytes_read == 0)
> +{
> +break;
> +}
> +else
> +{
> +offset += bytes_read;
> +num_bytes += bytes_read;
> +bytes_left -= bytes_read;
> +pos += bytes_read;
> +}
>  }
>  }
>  else
>
>
>
> Sent from Outlook 
>
>
> --
> *From:* Greg Clayton 
> *Sent:* Monday, October 17, 2016 12:39 PM
> *To:* Eugene Birukov
> *Cc:* LLDB
> *Subject:* Re: [lldb-dev] File::Read does not read everything
>
> It is probably best to make the code loop as long as "bytes_reads > 0" and
> we haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read
> size which gets set to MAX_READ_SIZE, but we need to do that because if you
> try to read more than that it reads nothing. So MAX_READ_SIZE is more for
> the case where the read will outright fail if given a byte size that is too
> large. Feel free to submit a patch that can keep calling pread correctly in
> a loop as long as bytes_read > 0.
>
> Greg
>
> > On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >
> > I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is
> located on Windows file share mounted on Linux via mount.cifs. I see that
> we successfully allocated memory and are trying to fill it in one read.
> Unfortunately pread returns 2GiB and we never check for short read here.
> >
> > I think we could combine this code with previous block "#if defined
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too
> small) and loop until all the buffer is filled.
> >
> > Thanks,
> > Eugene
> >
> > #ifndef _WIN32
> > int fd = GetDescriptor();
> > if (fd != kInvalidDescriptor)
> > {
> > ssize_t bytes_read = -1;
> > do
> > {
> > bytes_read = ::pread (fd, buf, num_bytes, offset);
> > } while (bytes_read < 0 && errno == EINTR);
> >
> > if (bytes_read < 0)
> > {
> > num_bytes = 0;
> > error.SetErrorToErrno();
> > }
> > else
> > {
> > offset += bytes_read;
> > num_bytes = bytes_read;
> > }
> > }
> >
> > Sent from Outlook
> > ___
> > 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

Re: [lldb-dev] File::Read does not read everything

2016-10-17 Thread Eugene Birukov via lldb-dev

Done. https://reviews.llvm.org/D25712


Sent from Outlook



From: Zachary Turner 
Sent: Monday, October 17, 2016 5:24 PM
To: Eugene Birukov; Greg Clayton
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

http://reviews.llvm.org. Create an account there and upload patch
On Mon, Oct 17, 2016 at 5:15 PM Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

Sorry for noob's question: what is "phabricator"?

Sure, I will do it as soon as I understand what you want me to do :)


Sent from Outlook



From: Zachary Turner mailto:ztur...@google.com>>
Sent: Monday, October 17, 2016 5:01 PM
To: Eugene Birukov; Greg Clayton

Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything
Can you upload a diff (with context) to phabricator and add lldb-commits as a 
subscriber and myself / Greg as reviewers?

On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Here is what I am running now:


diff --git a/source/Host/common/File.cpp b/source/Host/common/File.cpp
index 89587a9..a4ac25e 100644
--- a/source/Host/common/File.cpp
+++ b/source/Host/common/File.cpp
@@ -771,21 +771,34 @@ File::Read (void *buf, size_t &num_bytes, off_t &offset)
 int fd = GetDescriptor();
 if (fd != kInvalidDescriptor)
 {
-ssize_t bytes_read = -1;
-do
+size_t bytes_left = num_bytes;
+num_bytes = 0;
+char *pos = (char*)buf;
+while (bytes_left > 0)
 {
-bytes_read = ::pread (fd, buf, num_bytes, offset);
-} while (bytes_read < 0 && errno == EINTR);
+ssize_t bytes_read = -1;
+do
+{
+bytes_read = ::pread (fd, pos, bytes_left, offset);
+} while (bytes_read < 0 && errno == EINTR);

-if (bytes_read < 0)
-{
-num_bytes = 0;
-error.SetErrorToErrno();
-}
-else
-{
-offset += bytes_read;
-num_bytes = bytes_read;
+if (bytes_read < 0)
+{
+num_bytes = 0;
+error.SetErrorToErrno();
+break;
+}
+else if (bytes_read == 0)
+{
+break;
+}
+else
+{
+offset += bytes_read;
+num_bytes += bytes_read;
+bytes_left -= bytes_read;
+pos += bytes_read;
+}
 }
 }
 else




Sent from Outlook



From: Greg Clayton mailto:gclay...@apple.com>>
Sent: Monday, October 17, 2016 12:39 PM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] File::Read does not read everything

It is probably best to make the code loop as long as "bytes_reads > 0" and we 
haven't read "num_bytes" yet. The darwin kernel has a INT32_MAX read size which 
gets set to MAX_READ_SIZE, but we need to do that because if you try to read 
more than that it reads nothing. So MAX_READ_SIZE is more for the case where 
the read will outright fail if given a byte size that is too large. Feel free 
to submit a patch that can keep calling pread correctly in a loop as long as 
bytes_read > 0.

Greg

> On Oct 17, 2016, at 12:20 PM, Eugene Birukov via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
> Hello,
>
> I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is 
> located on Windows file share mounted on Linux via mount.cifs. I see that we 
> successfully allocated memory and are trying to fill it in one read. 
> Unfortunately pread returns 2GiB and we never check for short read here.
>
> I think we could combine this code with previous block "#if defined 
> (MAX_READ_SIZE)" if we simply check for short read here (bytes_read too 
> small) and loop until all the buffer is filled.
>
> Thanks,
> Eugene
>
> #ifndef _WIN32
> int fd = GetDescriptor();
> if (fd != kInvalidDescriptor)
> {
> ssize_t bytes_read = -1;
> do
> {
> bytes_read = ::pread (fd, buf, num_bytes, offset);
> } while (bytes_read < 0 && errno == EINTR);
>
> if (bytes_read < 0)
> {
> num_bytes = 0;
> error.SetErrorToErrno();
> }
> else
> {
> offset += bytes_read;
> num_bytes = bytes_read;
> }
> }
>
> Sent from Outlook
> ___
> 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.

[lldb-dev] GitHub Survey Online

Re: [lldb-dev] add custom vendor commands

Re: [lldb-dev] unaligned cast in TCPSocket::Connect

Re: [lldb-dev] LLDB can't find source...but it can?

Re: [lldb-dev] LLDB can't find source...but it can?

Re: [lldb-dev] LLDB can't find source...but it can?

[lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

Re: [lldb-dev] File::Read does not read everything

13 matches

Site Navigation

Mail list logo

Footer information