[lldb-dev] Layout of FXSAVE struct for x86 Architectures in LLDB
Hi all I was looking into the file "source/Plugins/Process/Utility/RegisterContext_x86.h" and I noticed one thing in FXSAVE structure. The 'ftag' is defined as a 16 bit field. However, on referring to Architecture Software Developer Manual for x86 architectures, one can see that the memory layout of the contents of FXSAVE area has only 8 bits for 'ftag' register and rest of the 8 bits are reserved. Is there any specific reason of keeping 'ftag' field to be 16 bits in FXSAVE structure in LLDB for x86 Architectures? - Abhishek ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Layout of FXSAVE struct for x86 Architectures in LLDB
I'm using this doc: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf In table 10-2, and again in 13-1, it does appear to call out the most significant byte as reserved (byte 5). As do the instruction details. Looking at the in-memory layout of the FPU tag word in "8.1.7 x87 FPU Tag Word", it is clear all 16 bits are used in the runtime image, and the 8 bits of defined ftag state in the FXSAVE area are encoded/decoded as per byte 4's description in section 10.5.1. Seems fine to call it what it is - want to put up a patch? Just make sure you run all the tests as well. -Todd On Thu, Sep 24, 2015 at 2:44 AM, Abhishek Aggarwal via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all > > I was looking into the file > "source/Plugins/Process/Utility/RegisterContext_x86.h" and I noticed one > thing in FXSAVE structure. The 'ftag' is defined as a 16 bit field. > > However, on referring to Architecture Software Developer Manual for x86 > architectures, one can see that the memory layout of the contents of FXSAVE > area has only 8 bits for 'ftag' register and rest of the 8 bits are > reserved. Is there any specific reason of keeping 'ftag' field to be 16 > bits in FXSAVE structure in LLDB for x86 Architectures? > > > - Abhishek > > ___ > 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] [Bug 24926] New: OS X cmake failing tests after rL248338
https://llvm.org/bugs/show_bug.cgi?id=24926 Bug ID: 24926 Summary: OS X cmake failing tests after rL248338 Product: lldb Version: unspecified Hardware: PC OS: All 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 >From http://reviews.llvm.org/rL248338: === snip === Hi Enrico, This commit has caused catasrophic test failures on OSX. The failure count went up by 512. lldb is built with cmake/ninja, and tests are run in the test dir as follows: cd ~/llvm mkdir -p build_ninja && cd build_ninja cmake -G Ninja .. "-DLLVM_TARGETS_TO_BUILD=ARM;X86;AArch64" -DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++" -DCMAKE_BUILD_TYPE=Release security unlock-keychain -p /Users/testuser/Library/Keychains/login.keychain ninja cd ../tools/lldb/test ./dotest.py --output-on-success -v Can you have a look please? Thanks in advance, -Dawn === snip === I'm starting to look at this now. -- 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 24926] OS X cmake failing tests after rL248338
https://llvm.org/bugs/show_bug.cgi?id=24926 Todd Fiala changed: What|Removed |Added Hardware|PC |Macintosh Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- 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 24928] New: Evaluating expression returning an std::shared_ptr fails
https://llvm.org/bugs/show_bug.cgi?id=24928
Bug ID: 24928
Summary: Evaluating expression returning an std::shared_ptr
fails
Product: lldb
Version: unspecified
Hardware: PC
OS: All
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 with the following command on Linux x86_64: "clang++
-g -std=c++11 main.cpp", then set a breakpoint on the marked line and evaluate
the expression "foo(sp)" while stopped at the breakpoint.
Expected behavior is to display the result of the expression, but lldb returns
with the following error message:
call to a function 'std::__shared_ptr::~__shared_ptr()'
('_ZNSt12__shared_ptrIiN9__gnu_cxx12_Lock_policyEED2Ev') that is not present in
the target
Tested on Linux x86_64 with clang-3.5 and gcc-4.8.4
#include
std::shared_ptr foo(const std::shared_ptr& sp) {
return sp;
}
int main() {
std::shared_ptr sp = std::make_shared(42);
auto sp2 = foo(sp);
return 0; // Break here and run "expression foo(sp)"
}
--
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
Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses
> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote: > > On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote: >> We currently coalesce breakpoints to avoid the user stopping multiple times >> on the same source line. This might have been done to avoid stepping issues >> we might have had in the past, but we have made many modifications to >> stepping such that the step thread plans now know how to step through two >> hits from the same source line. I would need Jim to confirm this, but he is >> out for 2 weeks. > > I (think I) understand the intent, but it is wrong as written. What I > think the code is trying to do is remove duplicate lines within a basic > block (or at least that's the only explanation I can come up with that > makes any sense), but the code appears to assume Block == basic block, > which is not true. > > As long as there is branching into/out of an address range, you can miss > breakpoints, which is much worse than stepping to the same line twice, > wouldn't you agree? Note that this isn't even in optimized code - this > issue will be far more common after the optimizer has played with it. > > As you say, we might have to wait for Jim to hear the real answer. > If this turns out to be intentional, OK to add an option to control it? I only want to add options if we have a split community on what the right thing to do is. I believe we should be able to come up with a solution that makes sense that everyone will like. You might check the SVN history on the line to see if that sheds any light on the issue. So lets first try to fix it correctly so everyone is happy without adding an option. >> So this is on purpose and is expected. Not sure what will happen if we >> disable this coalescing of locations that are contiguous. Feel free to try >> and disable it and run the test suite and see how things go. Don't check >> anything in, but you could try disabling it on your branch and see how >> things go. Then when Jim returns we can confirm with him what the right >> thing to do is. > > Sure - will do. > > Thanks! > -Dawn ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses
On Thu, Sep 24, 2015 at 02:34:39PM -0700, Greg Clayton wrote: > > I only want to add options if we have a split community on what the right > thing to do is. I believe we should be able to come up with a solution that > makes sense that everyone will like. You might check the SVN history on the > line to see if that sheds any light on the issue. So lets first try to fix it > correctly so everyone is happy without adding an option. Agreed. > >> So this is on purpose and is expected. Not sure what will happen if we > >> disable this coalescing of locations that are contiguous. Feel free to try > >> and disable it and run the test suite and see how things go. Don't check > >> anything in, but you could try disabling it on your branch and see how > >> things go. Then when Jim returns we can confirm with him what the right > >> thing to do is. > > > > Sure - will do. I ran tests with the code disabled locally on OSX. When tests are compiled with clang-602.0.53 (based on llvm 3.6.0svn), we see an additional 34 failures in the lldb tests, and when tested with clang-503.0.40 (based on llvm 3.4svn), we see only 6 additional failures. Most tests are failing because the num_expected_locations is no longer 1. For that, we could change run_break_set_by_file_and_line to have num_expected_locations=-1 mean "any number of locations", and if num_expected_locations == -1, check that the location count is >= 1 (and of course, fix the affected tests). Other tests are harder to fix, because they'd need additional "continue"s added as needed. But we can't hard-code the number of BP locations in those cases, as we've already seen differences based on the version of clang, and llvm could schedule the code differently based on optimizations or platform. So we'd need a way to get the number of BP locations and conditionally add "continue"s, but even that would also be dependant on llvm's codegen. FYI - the 6 test which fail in both older and newer clangs are: CreateAfterAttachTestCase.test_create_after_attach_with_dsym CreateAfterAttachTestCase.test_create_after_attach_with_dwarf_and_fork CreateAfterAttachTestCase.test_create_after_attach_with_dwarf_and_popen ThreadExitTestCase.test_with_dsym TypeCompletionTestCase.test_with_dsym_and_run_command TypeCompletionTestCase.test_with_dwarf_and_run_command -Dawn ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
