[lldb-dev] [Bug 29046] New: SymbolFilePDBTests gtests core dumps on macOS

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=29046

Bug ID: 29046
   Summary: SymbolFilePDBTests gtests core dumps on macOS
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

In updating the macOS Xcode lldb-gtest target to include all the newer tests
people have been adding, I'm finding that the SymbolFilePDBTests seg faults on
macOS 10.12 Beta 6:

[--] 1 test from SymbolFilePDBTests
[ RUN  ] SymbolFilePDBTests.TestAbilitiesForDWARF
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp:181:
Failure
Expected: (nullptr) != (plugin), actual: 8-byte object <00-00 00-00 00-00
00-00> vs NULL
/Volumes/Data/src/lldb-llvm.org/lldb/build/lldb.build/Debug/lldb-gtest.build/Script-23B9815E1CB2E2F90059938A.sh:
line 24:  8851 Segmentation fault: 11  ${BUILT_PRODUCTS_DIR}/lldb-gtest
--gtest_output=xml:${BUILD_DIR}/gtest-results.xml < /dev/null

I'm removing SYmbolFilePDBTests from the lldb-gtest target until this is
resolved.

-- 
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 29045] New: ModuleCacheTest gtest fails on macOS

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=29045

Bug ID: 29045
   Summary: ModuleCacheTest gtest fails on macOS
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

In refreshing the macOS Xcode lldb-gtest target to include all the newer gtests
that are not yet there, I am finding that the ModuleCacheTest test currently
fails on macOS:

[--] 3 tests from ModuleCacheTest
[ RUN  ] ModuleCacheTest.GetAndPut
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:128:
Failure
Value of: ec
  Actual: true
Expected: false
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:135:
Failure
Value of: error.Success()
  Actual: false
Expected: true
Error was: Failed to put module into cache: Failed to rename file
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPut/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/.temp
to
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPut/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/TestModule.so:
No such file or directory
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:136:
Failure
Value of: did_create
  Actual: false
Expected: true
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:137:
Failure
Value of: bool(module_sp)
  Actual: false
Expected: true
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:102:
Failure
Value of: uuid_view.Exists()
  Actual: false
Expected: true
uuid_view is:
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPut/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/TestModule.so
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:103:
Failure
Value of: uuid_view.GetByteSize()
  Actual: 0
Expected: module_size
Which is: 5602
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:106:
Failure
Value of: sysroot_view.Exists()
  Actual: false
Expected: true
sysroot_view is:
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPut/dummy_hostname/bin/TestModule.so
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:107:
Failure
Value of: sysroot_view.GetByteSize()
  Actual: 0
Expected: module_size
Which is: 5602
[  FAILED  ] ModuleCacheTest.GetAndPut (3 ms)
[ RUN  ] ModuleCacheTest.GetAndPutUuidExists
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:164:
Failure
Value of: ec
  Actual: true
Expected: false
[  FAILED  ] ModuleCacheTest.GetAndPutUuidExists (0 ms)
[ RUN  ] ModuleCacheTest.GetAndPutStrangeHostname
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:128:
Failure
Value of: ec
  Actual: true
Expected: false
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:135:
Failure
Value of: error.Success()
  Actual: false
Expected: true
Error was: Failed to put module into cache: Failed to rename file
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPutStrangeHostname/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/.temp
to
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPutStrangeHostname/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/TestModule.so:
No such file or directory
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:136:
Failure
Value of: did_create
  Actual: false
Expected: true
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:137:
Failure
Value of: bool(module_sp)
  Actual: false
Expected: true
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:102:
Failure
Value of: uuid_view.Exists()
  Actual: false
Expected: true
uuid_view is:
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPutStrangeHostname/.cache/F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476/TestModule.so
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:103:
Failure
Value of: uuid_view.GetByteSize()
  Actual: 0
Expected: module_size
Which is: 5602
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:106:
Failure
Value of: sysroot_view.Exists()
  Actual: false
Expected: true
sysroot_view is:
/var/folders/0w/klq9nv2j7c35lygnl43hpcq4gn/T/./lldb/8493/GetAndPutStrangeHostname/tab_colon_asterisk_/bin/TestModule.so
/Volumes/Data/src/lldb-llvm.org/lldb/unittests/Utility/ModuleCacheTest.cpp:107:
Failure
Value of: sysroot_view.GetByteSize()
  Actual: 0
Expected: module_size
Which is: 5602
[  FAILED  ] ModuleCacheTest.GetAndPutStrangeHostname (1 ms)
[--] 3 tests from ModuleCacheTest (4 ms total)

I am not including this test in the 

Re: [lldb-dev] lldb remote debuting failing

[Greg Clayton via lldb-dev]

> On Aug 18, 2016, at 2:37 AM, via lldb-dev  wrote:
> 
> Hi All,
> 
> I am trying to remote debug. My code is on 10.11 and my test machine is 
> 10.12, Sierra. I am using Xcode 5 on both machines. I am following below 
> steps for remote debugging:
> Test machine
> -
> cd 
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources
> 
> ./debugserver 192.168.116.130:12345 --attach=408
> 
> Code build machine
> —
> lldb
> process connect connect://192.168.116.151:12345
> b main.c:8
> 
> 
> This works fine if both build and test machines are 10.11 but fails with 
> below error if test machine is 10.12 and build machine is 10.11: 
> 
> 
>  process connect connect://192.168.116.187:12345
> Assertion failed: (!"Unhandled architecture in 
> PlatformDarwin::GetSoftwareBreakpointTrapOpcode()"), function 
> GetSoftwareBreakpointTrapOpcode, file 
> /SourceCache/lldb/lldb-300.2.53/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp,
>  line 437.
> 
> 
> Any suggestions to fix this?

Try the following:
1 - mount the root file system of your remote machine on your local machine 
using AFP (and lets pretend it end up at "/Volumes/RemoteMachine")
2 - select the remote-macosx platform and specify the sysroot:

(lldb) platform select remote-macosx --sysroot /Volumes/RemoteMachine
(lldb) process connect connect://192.168.116.187:12345


Let us know how that goes.

> 
> 
> -- 
> Have a nice day!
> Regards,
> Dipti
> ___
> 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] LLDB Evolution

[Kate Stone via lldb-dev]

If there’s consensus on a reasonable automated formatting solution for Python 
then I’m fine with going ahead and doing so at the same time.  The PEP-8 
standard would leave Python code with 4-space indentation, and impart a 
consistent look to our code.  Earlier this week I verified that our current 
repository builds and passes tests cleanly under the following conditions:

LLVM-style default .clang-format specified at the root of the tree:

BasedOnStyle: LLVM

Formatting disabled using .clang-format in packages/Python/lldbsuite.  It’s not 
just a matter of comment style and location driving tests.  The tests 
themselves are exercising debugging functionality driven by debug information 
line tables.  Debugging behavior can and will change when using line-oriented 
requests (breakpoint on a particular line, step over a particular line, etc.):

DisableFormat: true

# Disabling formatting doesn't implicitly disable include sorting
SortIncludes: false

Formatting automatically applied for all .c, .h, and .cpp sources in the tree

I’ll run the full suite again following reformatting using autopep8 
 for all .py files.

Thanks to everyone who has chimed in with suggestions, and with contributions 
to ensure that include ordering doesn’t become an issue on other platforms.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev 
>  wrote:
> 
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev 
> > wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
> 
> 
> (Comment from the peanut gallery...)
> 
> Python does have a language-level style guide (PEP-8):
> 
> https://www.python.org/dev/peps/pep-0008/ 
> 
> 
> If code is going to be reformatted, then it may be best to try to converge on 
> exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an 
> active contributor), but someone with Python background, anything that 
> diverges from standard Python style seems jarring (at least to me).
> 
>  
> It will take some editor tweaking to make it use the correct indent
> for different files, but it should be manageable.
> 
> pl
> 
> On 12 August 2016 at 18:13, Jim Ingham  > wrote:
> >
> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev 
> >> > wrote:
> >>
> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> >> > wrote:
> >>> I recommend approaching this in three steps:
> >>>
> >>> 1) get the less-controversial changes done that Greg was outlining.
> >>> 2) start a discussion in the llvm community about the concept of a
> >>> member/global prefix.
> >>> 2a) the community could agree that llvm-as-a-whole should move to prefixes
> >>> or otherwise change the camel case policy.
> >>> 2b) the community could agree that the existing policies are preferred
> >>> 3) LLDB moves to whatever is the end result of the discussion.
> >>>
> >>> I guess what I’m saying is that since the opinions about this are very
> >>> strong, and because we haven’t really had that debate in the LLVM 
> >>> community,
> >>> that it would be bad to proactively move to the LLVM style, simply to have
> >>> to move back later.  Iff the (sure to be extensive) community discussion
> >>> settles on the idea that prefixes are the wrong thing, then LLDB should
> >>> remove them to be consistent.
> >>>
> >>> -Chris
> >>
> >> +1
> >>
> >>
> >>
> >> In terms of the formatting of tests, I did some more research on this.
> >> I think the changes needed to be made to the test suite are generally
> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
> >> does prevent clang-format from breaking the comment, but it does not
> >> prevent it from moving the whole comment to a new line. That said,
> >> when I reformatted the test sources with CommentPragmas set, the
> >> number of failures went down to 80 (from about 150)...
> >>
> >> I believe we should still perform the reformatting of the tests, at
> >> least to standardize on the 2 space indent (in fact we should consider
> >> doing the same for the python code as well, I don't know what's the
> >> situation there in llvm land), but it can be done later. It will make
> >> the period while the code is in flux longer, but hopefully not too
> >> long. Also the modifications will be independent of the main reformat,
> >> so it will still be true that a single source file only got
> >> reformatted once.
> >>
> >
> 

Re: [lldb-dev] showing CPU register flags

[Giusti, Valentina via lldb-dev]

Thanks for your replies!

@Greg, I think I will start by trying your approach and then I will get back to 
you with some feedback in a couple of days.

Cheers,
- Valentina

> -Original Message-
> > I am currently implementing the support for the Intel MPX registers in LLDB.
> This register set includes 2 registers, BNDSTATUS and BNDCFGU, which store
> information about the status and configuration of the MPX feature in several
> fields.
> > I think that it would be useful for the user to have a nice display of such 
> > fields,
> so that they don't have to extract the information from the raw values of the
> registers. However, I see that the other registers are just displayed as raw
> values, without any better ways to explore their contents.
> >
> > Should I just follow this approach, and also just let the MPX registers be
> available through their raw values?
> > Or have there ever been any requests for ways to display the register flags
> from LLDB?
> 
> We haven't done anything fancy for registers yet. I see a few ways to do this:
> 
> 1 - allow register values to specify a CompilerType as the way to display the
> register. Right now registers always default to use simple built in types:
> 
> 
> CompilerType
> ValueObjectRegister::GetCompilerTypeImpl () {
> if (!m_compiler_type.IsValid())
> {
> ExecutionContext exe_ctx (GetExecutionContextRef());
> Target *target = exe_ctx.GetTargetPtr();
> if (target)
> {
> Module *exe_module = target->GetExecutableModulePointer();
> if (exe_module)
> {
> TypeSystem *type_system = exe_module->GetTypeSystemForLanguage
> (eLanguageTypeC);
> if (type_system)
> m_compiler_type = type_system-
> >GetBuiltinTypeForEncodingAndBitSize (m_reg_info.encoding,
>   
>m_reg_info.byte_size * 8);
> }
> }
> }
> return m_compiler_type;
> }
> 
> 
> so we currently take the encoding and byte size and make a built in type for 
> it.
> We could allow a RegisterContext to manually create types using for a given
> target.
> 
> We might allow RegisterInfo structs to have an extra field that is expression 
> text
> that defines a register type something like:
> 
> const char *my_register_type = "typedef enum EnumType { eValueA, eValueB,
> eValueC}; struct reg_type { uint8_t a : 7, b:2, c:2; EnumType enum; }"
> 
> Then we could use the top level expression parser to parse the expression and
> extract the "reg_type" as a CompilerType from the source code. Then you could
> define any type you want for your register. Sean Callanan will be able to help
> with expression parser details if this sounds like something you would like 
> to do.
> I can help with the rest of the plumbing.
> 
> Greg Clayton
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] lldb remote debuting failing

[via lldb-dev]

Hi All,

I am trying to remote debug. My code is on 10.11 and my test machine is
10.12, Sierra. I am using Xcode 5 on both machines. I am following below
steps for remote debugging:

Test machine

-

cd
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources


./debugserver 192.168.116.130:12345 --attach=408

Code build machine
—
lldb

process connect connect://192.168.116.151:12345

b main.c:8


This works fine if both build and test machines are 10.11 but fails with
below error if test machine is 10.12 and build machine is 10.11:


 process connect connect://192.168.116.187:12345

Assertion failed: (!"Unhandled architecture in
PlatformDarwin::GetSoftwareBreakpointTrapOpcode()"), function
GetSoftwareBreakpointTrapOpcode, file
/SourceCache/lldb/lldb-300.2.53/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp,
line 437.


Any suggestions to fix this?

-- 
Have a nice day!
Regards,
Dipti
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev