[lldb-dev] [Bug 40668] `ninja` does not rebuild if sources change
https://bugs.llvm.org/show_bug.cgi?id=40668 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40669] cannot pass SIGSEGV / EXC_BAD_ACCESS on OSX
https://bugs.llvm.org/show_bug.cgi?id=40669 Jim Ingham changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||jing...@apple.com --- Comment #1 from Jim Ingham --- This is a general feature of the Darwin kernel, and is not architecture or OS dependent. So this is strictly a dup of 22868. *** This bug has been marked as a duplicate of bug 22868 *** -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40669] New: cannot pass SIGSEGV / EXC_BAD_ACCESS on OSX
https://bugs.llvm.org/show_bug.cgi?id=40669 Bug ID: 40669 Summary: cannot pass SIGSEGV / EXC_BAD_ACCESS on OSX Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: thelastmamm...@gmail.com CC: llvm-b...@lists.llvm.org This is similar to https://bugs.llvm.org/show_bug.cgi?id=22868 (which was for ARM / iOS) but I'm having that issue in OSX as well: this is still relevant for OSX: > lldb always stops on EXC_BAD_ACCESS and will not continue. The result is > SIGSEGV cannot be passed. That is, this does not work: process handle SIGSEGV --stop false --pass true --notify false > Programs that expect to continue processing by turning SIGSEGV into an > exception cannot be run under lldb. * note: this is root cause for https://github.com/nim-lang/Nim/issues/9753 (lldb can't continue on NilAccessError, stuck after EXC_BAD_ACCESS #9753) * note: also reported in here: https://stackoverflow.com/questions/26829119/how-to-make-lldb-ignore-exc-bad-access-exception * I tried the suggestion from here: https://stackoverflow.com/questions/26829119/how-to-make-lldb-ignore-exc-bad-access-exception/32724035#32724035 by re-compiling lldb by changing tools/debugserver/source/MacOSX/MachTask.mm: ``` err = ::task_set_exception_ports (task, m_exc_port_info.mask & ~EXC_MASK_BAD_ACCESS, m_exception_port, EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES, THREAD_STATE_NONE); ``` but that had 0 effect * there's also this follow-up comment https://stackoverflow.com/questions/26829119/how-to-make-lldb-ignore-exc-bad-access-exception/32724035#comment94068788_26853954 but I don't know what to make of it -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40668] New: `ninja` does not rebuild if sources change
https://bugs.llvm.org/show_bug.cgi?id=40668 Bug ID: 40668 Summary: `ninja` does not rebuild if sources change Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: thelastmamm...@gmail.com CC: llvm-b...@lists.llvm.org I'm on OSX and follow the steps here: https://lldb.llvm.org/build.html ``` git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake ../llvm -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb' ninja lldb ``` this works, but then if I change sources [1], nothing is rebuilt after `ninja lldb`, which completes almost immediately: ``` ninja lldb [1/1] Python script sym-linking LLDB Python API ``` ## note: here's the change I was trying to make: * trying to apply this patch https://stackoverflow.com/a/32724035/1426932 to fix this bug https://stackoverflow.com/questions/26829119/how-to-make-lldb-ignore-exc-bad-access-exception if i modify llvm-project/lldb/tools/debugserver/source/MacOSX/MachTask.mm no recompilation happens; ditto with `source/Plugins/Process/Darwin/MachException.cpp` -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch
On 02/06/2019 10:57 PM, Michał Górny wrote:
> On Wed, 2019-02-06 at 14:09 -0800, Tom Stellard wrote:
>> On 02/05/2019 10:41 PM, Michał Górny wrote:
>>> On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote:
On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote:
> On 02/05/2019 11:26 AM, Michał Górny wrote:
>> On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote:
>>> On 02/05/2019 08:07 AM, Michał Górny wrote:
On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
wrote:
> Hi,
>
> The release_70 branch is ready for the 7.1.0 release. I have updated
> the
> version and pushed a fix for
> https://bugs.llvm.org/show_bug.cgi?id=39427,
> which is the only bug we will be fixing in this release.
>
> Since this is an ABI breaking changing and also we are introducing a
> minor version for the first time, please take some time to test the
> branch and make sure everything works as expected. I'm going
> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
> activity around the release calms down a little.
>
The SOVERSION is still '7'. Maybe we should force it to '7.1' here?
>>>
>>> It should already be changed. This is what I get when I build:
>>>
>>> [tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
>>> SONAME libLLVM-7.1.so
>>>
>>
>> I'm talking about SOVERSION of shared libs from BUILD_SHARED_LIBS=ON.
>> The one defined in llvm_add_library() function:
>>
>> set_target_properties(${name}
>> PROPERTIES
>> # Since 4.0.0, the ABI version is indicated by the major version
>> SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}
>> VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX})
>>
>
> Ok, I see. You are correct, we should change the soname on those. I can
> fix this.
>
This should be fixed now by r353247, can you re-test?
>>>
>>> Yes, though I don't think returning to '71' is a good idea. It
>>> introduces a value that is technically larger than '8', and people
>>> running ldconfig(1) will get libs relinked to .so.71 all the time.
>>> Putting a dot there should be safer.
>>>
>>
>> This is fixed now in r353348. Can you test again?
>>
>
> You forgot to update VERSION as well.
>
This should be fixed now in r353565. Let me know if there are any other issues.
-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Odd intermittent test error
Does anyone know what causes this? I see it on our bots intermittently, but haven't been able to reproduce it locally. The test passes, but something unnamed crashes, and the test is marked as failed. TEST 'lldb-Suite :: functionalities/data-formatter/synthcapping/TestSyntheticCapping.py' FAILED ... PASS: LLDB (/local/mnt/workspace/bots/hexbotmaster-sles11_sd_0/hexagon-clang-83/build_tools/Tools/bin/clang-7-v67) :: test_with_run_command_dwarf (TestSyntheticCapping.SyntheticCappingTestCase) ... -- Ran 4 tests in 0.225s RESULT: PASSED (1 passes, 0 failures, 0 errors, 3 skipped, 0 expected failures, 0 unexpected successes) terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument ... Failing Tests (1): lldb-Suite :: functionalities/data-formatter/synthcapping/TestSyntheticCapping.py ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Unwinding + Symbol Files: How To?
Hello Jason, Greg, thank you for the feedback. Please find my responses inline. On 08/02/2019 04:06, Jason Molenda wrote: Hi Pavel, I'm open to this. I don't think there was any specific reason why UnwindTable is in the ObjectFile over the Module - it was very likely not an intentional choice when I put it there. Cool. Thanks. Are you proposing removing the hardcoded rules in FuncUnwinders of which unwind plan sources to prefer in different situations? I'm not against it, but the # of unwind sources has been small enough that it hasn't been too much of a problem imo. At the moment, probably not. I've played around with the idea while experiment and trying to figure out how to make this work, but I haven't been able to come up with something which is significantly better than the current code. So, I'll probably just insert this new "symbol file unwind plan" into the hardcoded list of priorities. TBH, the exact place probably doesn't matter much since it is unlikely that a single function would have both eh_frame data and pdb/breakpad unwind info. eh_frame and debug_frame are the most annoying formats because they CAN be accurate at every instruction location, if the producer decided to do that. Or they may only be accurate for the prologue. (often called "asynchronous unwind tables" when it is accurate at every instruction) But there's nothing in the eh_frame/debug_frame spec that tells the consumer (lldb) what kind of unwind source this is. On 07/02/2019 19:18, Greg Clayton wrote: > We also have information that is generated, like assembly unwind, ABI > plug-ins (I believe) which give out the arch defaults for how to > unwind at the first instruction of the function, and also one that > unwinds when you are in the middle (follow the frame pointer and PC > is at FP-). It would be great if this could live in the > Module and also be generated without having to have a live process. > Many tools I know of would love to be able to get to and enumerate > our unwind info via the public API, especially the assembly unwind > info. I am also interested in something like that, though this will probably be a separate endeavour and not a part of getting making breakpad unwind info parsing effort. regards, pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
