[Lldb-commits] [PATCH] D35083: [TypeSystem] Guard the global `ASTSourceMap` with a mutex

2017-07-24 Thread Jim Ingham via Phabricator via lldb-commits 
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Ack!  I thought when you said you were "going to simply pass..." you hadn't 
done it yet, so I didn't look at the source changes.

Anyway, this looks fine to me.


Repository:
  rL LLVM

https://reviews.llvm.org/D35083



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

[Lldb-commits] [lldb] r308933 - Extend 'target symbols add' to load symbols from a given module

2017-07-24 Thread Eugene Zemtsov via lldb-commits 
Author: eugene
Date: Mon Jul 24 15:52:39 2017
New Revision: 308933

URL: http://llvm.org/viewvc/llvm-project?rev=308933=rev
Log:
Extend 'target symbols add' to load symbols from a given module

Now -shlib flag can be provided alongside with names of symbols files:

(lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so

This is helpful when default matching mechanisms by name and UUID
can't find a module, and the user needs to explicitly specify
which module the given symbol file belongs to.

Differential Revision: https://reviews.llvm.org/D35607

Added:
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/Makefile

lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/TestTargetSymbolsAddCommand.py
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/main.c
Modified:
lldb/trunk/source/Commands/CommandObjectTarget.cpp
lldb/trunk/source/Interpreter/CommandObject.cpp

Added: lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/Makefile?rev=308933=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/Makefile (added)
+++ lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/Makefile Mon 
Jul 24 15:52:39 2017
@@ -0,0 +1,12 @@
+LEVEL = ../../make
+CXX_SOURCES := main.cpp
+LD_EXTRAS += -Wl,--build-id=none
+
+localall : stripped.out all
+stripped.out : a.out
+  $(OBJCOPY) 
--remove-section=.note.gnu.build-id --remove-section=.gnu_debuglink 
--strip-debug a.out stripped.out
+
+clean::
+   $(RM) stripped.out
+
+include $(LEVEL)/Makefile.rules
\ No newline at end of file

Added: 
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/TestTargetSymbolsAddCommand.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/TestTargetSymbolsAddCommand.py?rev=308933=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/TestTargetSymbolsAddCommand.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/TestTargetSymbolsAddCommand.py
 Mon Jul 24 15:52:39 2017
@@ -0,0 +1,52 @@
+""" Testing explicit symbol loading via target symbols add. """
+import os
+import time
+import lldb
+import sys
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TargetSymbolsAddCommand(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+self.source = 'main.c'
+
+@no_debug_info_test  # Prevent the genaration of the dwarf version of this 
test
+@skipUnlessPlatform(['linux'])
+def test_target_symbols_add(self):
+"""Test that 'target symbols add' can load the symbols
+even if gnu.build-id and gnu_debuglink are not present in the module.
+Similar to test_add_dsym_mid_execution test for macos."""
+self.build(clean=True)
+exe = os.path.join(os.getcwd(), "stripped.out")
+
+self.target = self.dbg.CreateTarget(exe)
+self.assertTrue(self.target, VALID_TARGET)
+
+main_bp = self.target.BreakpointCreateByName("main", "stripped.out")
+self.assertTrue(main_bp, VALID_BREAKPOINT)
+
+self.process = self.target.LaunchSimple(
+None, None, self.get_process_working_directory())
+self.assertTrue(self.process, PROCESS_IS_VALID)
+
+# The stop reason of the thread should be breakpoint.
+self.assertTrue(self.process.GetState() == lldb.eStateStopped,
+STOPPED_DUE_TO_BREAKPOINT)
+
+exe_module = self.target.GetModuleAtIndex(0)
+
+# Check that symbols are not loaded and main.c is not know to be
+# the source file.
+self.expect("frame select", substrs=['main.c'], matching=False)
+
+# Tell LLDB that a.out has symbols for stripped.out
+self.runCmd("target symbols add -s stripped.out a.out")
+
+# Check that symbols are now loaded and main.c is in the output.
+self.expect("frame select", substrs=['main.c'])

Added: lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/main.c?rev=308933=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/main.c (added)
+++ lldb/trunk/packages/Python/lldbsuite/test/linux/add-symbols/main.c Mon Jul 
24 15:52:39 2017
@@ -0,0 +1,6 @@
+#include 
+static int var = 5;
+int main() {
+  printf("%p is %d\n", , var);
+  return ++var;
+}

[Lldb-commits] [PATCH] D35607: Extend 'target symbols add' to set symbol file for a given module

2017-07-24 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

> Greg, are you with me checking this in?

Sure thing


https://reviews.llvm.org/D35607



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

[Lldb-commits] [lldb] r308919 - Skip test_lldbmi_var_update on Darwin.

2017-07-24 Thread Sean Callanan via lldb-commits 
Author: spyffe
Date: Mon Jul 24 13:11:20 2017
New Revision: 308919

URL: http://llvm.org/viewvc/llvm-project?rev=308919=rev
Log:
Skip test_lldbmi_var_update on Darwin.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py?rev=308919=308918=308919=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py 
Mon Jul 24 13:11:20 2017
@@ -159,6 +159,7 @@ class MiVarTestCase(lldbmi_testcase.MiTe
 @skipIfWindows  # llvm.org/pr24452: Get lldb-mi tests working on Windows
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @skipIfLinux  # llvm.org/pr22841: lldb-mi tests fail on all Linux buildbots
+@skipIfDarwin # rdar://33462982
 @skipIfRemote   # We do not currently support remote debugging via the MI.
 def test_lldbmi_var_update(self):
 """Test that 'lldb-mi --interpreter' works for -var-update."""


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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

In https://reviews.llvm.org/D35734#819193, @probinson wrote:

> In https://reviews.llvm.org/D35734#818778, @tberghammer wrote:
>
> > This section have been already removed from Dwarf5 so I agree that we 
> > shouldn't spend too much time adding support for it.
>
>
> Compilers wanting to use type units and DWARF 4 should be emitting them in 
> the .debug_types section.  DWARF 5 kept the concept but moved them back into 
> the .debug_info section.  Supporting type units in general seems like a good 
> idea, and the only question is where they live and what the exact details of 
> the header look like.


I have a patch that adds support for .debug_types seamlessly with DWARF5:

https://reviews.llvm.org/D32167

I haven't gotten the time to complete it and get all the buildbots clean, but 
it is in the queue.


Repository:
  rL LLVM

https://reviews.llvm.org/D35734



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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Phabricator via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL308911: Don't allow .debug_types to be parsed as LLDB can 
crash when enums are not able… (authored by gclayton).

Changed prior to commit:
  https://reviews.llvm.org/D35734?vs=107710=107936#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35734

Files:
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -497,6 +497,21 @@
 if (section_list == NULL)
   return 0;
 
+// On non Apple platforms we might have .debug_types debug info that
+// is created by using "-fdebug-types-section". LLDB currently will try
+// to load this debug info, but it causes crashes during debugging when
+// types are missing since it doesn't know how to parse the info in
+// the .debug_types type units. This causes all complex debug info
+// types to be unresolved. Because this causes LLDB to crash and since
+// it really doesn't provide a solid debuggiung experience, we should
+// disable trying to debug this kind of DWARF until support gets
+// added or deprecated.
+if (section_list->FindSectionByName(ConstString(".debug_types"))) {
+  m_obj_file->GetModule()->ReportWarning(
+"lldb doesn’t support .debug_types debug info");
+  return 0;
+}
+
 uint64_t debug_abbrev_file_size = 0;
 uint64_t debug_info_file_size = 0;
 uint64_t debug_line_file_size = 0;


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -497,6 +497,21 @@
 if (section_list == NULL)
   return 0;
 
+// On non Apple platforms we might have .debug_types debug info that
+// is created by using "-fdebug-types-section". LLDB currently will try
+// to load this debug info, but it causes crashes during debugging when
+// types are missing since it doesn't know how to parse the info in
+// the .debug_types type units. This causes all complex debug info
+// types to be unresolved. Because this causes LLDB to crash and since
+// it really doesn't provide a solid debuggiung experience, we should
+// disable trying to debug this kind of DWARF until support gets
+// added or deprecated.
+if (section_list->FindSectionByName(ConstString(".debug_types"))) {
+  m_obj_file->GetModule()->ReportWarning(
+"lldb doesn’t support .debug_types debug info");
+  return 0;
+}
+
 uint64_t debug_abbrev_file_size = 0;
 uint64_t debug_info_file_size = 0;
 uint64_t debug_line_file_size = 0;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r308911 - Don't allow .debug_types to be parsed as LLDB can crash when enums are not able to be found.

2017-07-24 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Mon Jul 24 11:40:33 2017
New Revision: 308911

URL: http://llvm.org/viewvc/llvm-project?rev=308911=rev
Log:
Don't allow .debug_types to be parsed as LLDB can crash when enums are not able 
to be found.

Differential Revision: https://reviews.llvm.org/D35734


Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=308911=308910=308911=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Mon Jul 24 
11:40:33 2017
@@ -497,6 +497,21 @@ uint32_t SymbolFileDWARF::CalculateAbili
 if (section_list == NULL)
   return 0;
 
+// On non Apple platforms we might have .debug_types debug info that
+// is created by using "-fdebug-types-section". LLDB currently will try
+// to load this debug info, but it causes crashes during debugging when
+// types are missing since it doesn't know how to parse the info in
+// the .debug_types type units. This causes all complex debug info
+// types to be unresolved. Because this causes LLDB to crash and since
+// it really doesn't provide a solid debuggiung experience, we should
+// disable trying to debug this kind of DWARF until support gets
+// added or deprecated.
+if (section_list->FindSectionByName(ConstString(".debug_types"))) {
+  m_obj_file->GetModule()->ReportWarning(
+"lldb doesn’t support .debug_types debug info");
+  return 0;
+}
+
 uint64_t debug_abbrev_file_size = 0;
 uint64_t debug_info_file_size = 0;
 uint64_t debug_line_file_size = 0;


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

[Lldb-commits] [lldb] r308905 - RFix PR33875 by distinguishing between DWO and clang modules.

2017-07-24 Thread Adrian Prantl via lldb-commits 
Author: adrian
Date: Mon Jul 24 11:06:39 2017
New Revision: 308905

URL: http://llvm.org/viewvc/llvm-project?rev=308905=rev
Log:
RFix PR33875 by distinguishing between DWO and clang modules.

This reapplies https://reviews.llvm.org/D35740 with a tweak to find
the section by name rather than type. Section types don't distinguish
between regular sections and their DWO counterparts.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py?rev=308905=308904=308905=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
 Mon Jul 24 11:06:39 2017
@@ -9,8 +9,6 @@ class TestWithGmodulesDebugInfo(TestBase
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(bugnumber="llvm.org/pr33875", oslist=["linux"],
-compiler="clang", compiler_version=[">", "6.0"])
 @add_test_categories(["gmodules"])
 def test_specialized_typedef_from_pch(self):
 self.build()

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp?rev=308905=308904=308905=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp Mon Jul 
24 11:06:39 2017
@@ -61,6 +61,14 @@ SymbolFileDWARFDwo::ParseCompileUnit(DWA
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // Clang modules are found via a skeleton CU, but are not DWO
+  // objects. Clang modules have a .debug_info section instead of the
+  // *_dwo variant. Note that this is hardcoding the ELF section name
+  // based on the assumption that Mach-O does not use DWO objects.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByName(ConstString(".debug_info")))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);


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

[Lldb-commits] [PATCH] D35760: Expose active and available platform lists via SBDebugger API

2017-07-24 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

Huh, not sure how the other comment vanished.  I was concerned that 
"GetAvailablePlatformAtIndex" didn't actually get a platform, so the name was 
confusing.  I suggested GetAvailablePlatformInfoAtIndex as more accurate.


Repository:
  rL LLVM

https://reviews.llvm.org/D35760



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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

I believe a crash looks like:

  #include 
  
  int main(int argc, const char **argv) {
typedef enum FooTag {
  Bar,
  Baz
} Foo;
Foo foo = Bar;
printf("foo = %i\n", foo);
return 0; // Break here and "frame variable"
  }

The enum gets put into a type unit, and then we get an assertion when trying to 
get the byte size for an integer whose byte size is zero. -fdebug-types-section 
doesn't work on Mac as the flag is just ignored. Also, can we just assume 
"-fdebug-types-section" is available for any compiler that we run the LLDB test 
suite with? I am guessing that isn't the case so we should limit any test case 
to GCC or clang.

Can you compile the above code snippet and see if it crashes on linux?


https://reviews.llvm.org/D35734



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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

The enum might need to be scoped outside the function or in a header file...


https://reviews.llvm.org/D35734



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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Tamas Berghammer via Phabricator via lldb-commits 
tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.

Can you file a bug about this issue so we can keep track of it? Also it would 
be nice to include a small test case in the bug (if you have one) what 
demonstrates the crash as so far I only managed to see missing type information 
without an actual LLDB crash.




Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:513
+  return 0;
+}
+

clayborg wrote:
> That patch would be a lot more intrusive as we would still need to be able to 
> parse all compile unit DIEs just so we can get to the line tables. The only 
> way to find the line table for a compile unit is to follow the 
> DW_AT_stmt_list attribute in each top level compile unit DIE. Also, DWARF is 
> useless to us unless we index the DWARF, which means parsing everything in 
> all DIEs. I would like to keep this as simple as possible to just avoid the 
> issue for now. This make it easy to cherry pick this where needed for anyone 
> requiring this patch.
You are right.

I thought it is possible to use debug_lines without any information from the 
debug_info section but it is more complicated then that. In this case it would 
be almost as complicated to skip the problematic entries as to teach LLDB how 
to handle them.


https://reviews.llvm.org/D35734



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

[Lldb-commits] [PATCH] D33213: Use socketpair on all Unix platforms

2017-07-24 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Please init fd




Comment at: tools/lldb-server/lldb-gdbserver.cpp:388
   bool reverse_connect = false;
+  int connection_fd;
 

This must be initialized to -1 since only the 'F' case will store to this. 
Pretty much all of the time random memory would be used for this and 
incorrectly try to use a random integer as a file descriptor.


https://reviews.llvm.org/D33213



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

[Lldb-commits] [lldb] r308896 - Don't crash when hostname is empty. StringRef will assert and kill your program.

2017-07-24 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Mon Jul 24 09:47:04 2017
New Revision: 308896

URL: http://llvm.org/viewvc/llvm-project?rev=308896=rev
Log:
Don't crash when hostname is empty. StringRef will assert and kill your program.


Modified:
lldb/trunk/source/Utility/UriParser.cpp

Modified: lldb/trunk/source/Utility/UriParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/UriParser.cpp?rev=308896=308895=308896=diff
==
--- lldb/trunk/source/Utility/UriParser.cpp (original)
+++ lldb/trunk/source/Utility/UriParser.cpp Mon Jul 24 09:47:04 2017
@@ -43,7 +43,7 @@ bool UriParser::Parse(llvm::StringRef ur
   ((path_pos != std::string::npos) ? path_pos : uri.size()) - host_pos);
 
   // Extract hostname
-  if (host_port[0] == '[') {
+  if (!host_port.empty() && host_port[0] == '[') {
 // hostname is enclosed with square brackets.
 pos = host_port.find(']');
 if (pos == std::string::npos)


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

[Lldb-commits] [PATCH] D35734: Don't allow LLDB to try and parse .debug_types

2017-07-24 Thread Tamas Berghammer via Phabricator via lldb-commits 
tberghammer added a comment.

This section have been already removed from Dwarf5 so I agree that we shouldn't 
spend too much time adding support for it. Do you know anybody hitting this 
issue? Do you know why they decided to use this flag?




Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:500-513
+// On non Apple platforms we might have .debug_types debug info that
+// is created by using "-fdebug-types". LLDB currently will try to
+// load this debug info, but it causes crashes during debugging when
+// types are missing since it doesn't know how to parse the info in
+// the .debug_types type units. This causes all complex debug info
+// types to be unresolved. Because this causes LLDB to crash and since
+// it really doesn't provide a solid debuggiung experience, we should

Can we make this disabling logic a bit more fine grained? What I am thinking 
about is to disable parsing .debug_info and .debug_types but still parse the 
line table as that shouldn't cause any issue.



Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:501
+// On non Apple platforms we might have .debug_types debug info that
+// is created by using "-fdebug-types". LLDB currently will try to
+// load this debug info, but it causes crashes during debugging when

I think the name of the flag is "-fdebug-types-section" but it might be 
platform dependent.


https://reviews.llvm.org/D35734



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

[Lldb-commits] [PATCH] D35784: [LLD][MIPS] Fix Address::GetAddressClass() to return correct AddressClass based on the load address

2017-07-24 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain created this revision.
Herald added subscribers: arichardson, sdardis.

The implementation of Address::GetAddressClass() is based on file address. 
Those it will give incorrect result if there are more than one section for a 
particular file address. For example (see attach log), there are two sections 
(.text and .debug_ranges) for the file address 0xbcf0. Hence the 
Address::GetAddressClass() will return "eAddressClassDebug" instead of 
"eAddressClassCode". This will cause breakpoint failure and incorrect 
disassembly view. In these patch, the Address::GetAddressClass() will return 
AddressClass based on the loaded Section and fall back to file address if its 
failed.

F3765058: log 


https://reviews.llvm.org/D35784

Files:
  include/lldb/Symbol/ObjectFile.h
  include/lldb/lldb-enumerations.h
  source/Core/Address.cpp
  source/Symbol/ObjectFile.cpp

Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -315,6 +315,65 @@
   return false;
 }
 
+AddressClass ObjectFile::SectionTypeToAddressClass(const SectionType st) {
+  switch (st) {
+  case eSectionTypeInvalid:
+return eAddressClassUnknown;
+  case eSectionTypeCode:
+return eAddressClassCode;
+  case eSectionTypeContainer:
+return eAddressClassUnknown;
+  case eSectionTypeData:
+  case eSectionTypeDataCString:
+  case eSectionTypeDataCStringPointers:
+  case eSectionTypeDataSymbolAddress:
+  case eSectionTypeData4:
+  case eSectionTypeData8:
+  case eSectionTypeData16:
+  case eSectionTypeDataPointers:
+  case eSectionTypeZeroFill:
+  case eSectionTypeDataObjCMessageRefs:
+  case eSectionTypeDataObjCCFStrings:
+  case eSectionTypeGoSymtab:
+return eAddressClassData;
+  case eSectionTypeDebug:
+  case eSectionTypeDWARFDebugAbbrev:
+  case eSectionTypeDWARFDebugAddr:
+  case eSectionTypeDWARFDebugAranges:
+  case eSectionTypeDWARFDebugFrame:
+  case eSectionTypeDWARFDebugInfo:
+  case eSectionTypeDWARFDebugLine:
+  case eSectionTypeDWARFDebugLoc:
+  case eSectionTypeDWARFDebugMacInfo:
+  case eSectionTypeDWARFDebugMacro:
+  case eSectionTypeDWARFDebugPubNames:
+  case eSectionTypeDWARFDebugPubTypes:
+  case eSectionTypeDWARFDebugRanges:
+  case eSectionTypeDWARFDebugStr:
+  case eSectionTypeDWARFDebugStrOffsets:
+  case eSectionTypeDWARFAppleNames:
+  case eSectionTypeDWARFAppleTypes:
+  case eSectionTypeDWARFAppleNamespaces:
+  case eSectionTypeDWARFAppleObjC:
+return eAddressClassDebug;
+  case eSectionTypeEHFrame:
+  case eSectionTypeARMexidx:
+  case eSectionTypeARMextab:
+  case eSectionTypeCompactUnwind:
+return eAddressClassRuntime;
+  case eSectionTypeELFSymbolTable:
+  case eSectionTypeELFDynamicSymbols:
+  case eSectionTypeELFRelocationEntries:
+  case eSectionTypeELFDynamicLinkInfo:
+  case eSectionTypeOther:
+return eAddressClassUnknown;
+  case eSectionTypeAbsoluteAddress:
+return eAddressClassTypeAbsoluteAddress;
+  default:
+return eAddressClassUnknown;
+  }
+}
+
 AddressClass ObjectFile::GetAddressClass(addr_t file_addr) {
   Symtab *symtab = GetSymtab();
   if (symtab) {
@@ -324,68 +383,15 @@
 const SectionSP section_sp(symbol->GetAddressRef().GetSection());
 if (section_sp) {
   const SectionType section_type = section_sp->GetType();
-  switch (section_type) {
-  case eSectionTypeInvalid:
-return eAddressClassUnknown;
-  case eSectionTypeCode:
-return eAddressClassCode;
-  case eSectionTypeContainer:
-return eAddressClassUnknown;
-  case eSectionTypeData:
-  case eSectionTypeDataCString:
-  case eSectionTypeDataCStringPointers:
-  case eSectionTypeDataSymbolAddress:
-  case eSectionTypeData4:
-  case eSectionTypeData8:
-  case eSectionTypeData16:
-  case eSectionTypeDataPointers:
-  case eSectionTypeZeroFill:
-  case eSectionTypeDataObjCMessageRefs:
-  case eSectionTypeDataObjCCFStrings:
-  case eSectionTypeGoSymtab:
-return eAddressClassData;
-  case eSectionTypeDebug:
-  case eSectionTypeDWARFDebugAbbrev:
-  case eSectionTypeDWARFDebugAddr:
-  case eSectionTypeDWARFDebugAranges:
-  case eSectionTypeDWARFDebugFrame:
-  case eSectionTypeDWARFDebugInfo:
-  case eSectionTypeDWARFDebugLine:
-  case eSectionTypeDWARFDebugLoc:
-  case eSectionTypeDWARFDebugMacInfo:
-  case eSectionTypeDWARFDebugMacro:
-  case eSectionTypeDWARFDebugPubNames:
-  case eSectionTypeDWARFDebugPubTypes:
-  case eSectionTypeDWARFDebugRanges:
-  case eSectionTypeDWARFDebugStr:
-  case eSectionTypeDWARFDebugStrOffsets:
-  case eSectionTypeDWARFAppleNames:
-  case eSectionTypeDWARFAppleTypes:
-  case eSectionTypeDWARFAppleNamespaces: