The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets. Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.
Revisit the method of switching plugins. Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.
Update the test status. Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure. For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.
Differential Revision: https://reviews.llvm.org/D90757
This patch marks following tests as xfail for arm-linux target.
lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test
Bugs have been filed for all of them for the corresponding failing
component.
This reimplements commit 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
This reverts commit cf1046c716.
Reverted: https://reviews.llvm.org/D74252
It fixed testsuite but broke real world functionality where is not used:
settings set symbols.enable-external-lookup false
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
On Fedora 30 x86_64 I have:
$ readelf -Ws /lib64/libc.so.6 |grep '^Symbol\|.*assert_fail'
Symbol table '.dynsym' contains 2362 entries:
630: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail@@GLIBC_2.2.5
Symbol table '.symtab' contains 22711 entries:
922: 000000000002275a 15 FUNC LOCAL DEFAULT 14 __assert_fail_base.cold
18044: 0000000000030520 70 FUNC LOCAL DEFAULT 14 __GI___assert_fail
20081: 00000000000303a0 370 FUNC LOCAL DEFAULT 14 __assert_fail_base
21766: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail
The patch should never expect __GI___assert_fail:
.symtab can be present or not but that should not change that
__assert_fail always wins - it is always present from .dynsym and it can
never be overriden by __GI___assert_fail as __GI___assert_fail has only
local binding. Global binding is preferred since D63540.
External debug info symbols do not matter since D55859 (and DWARF should
never be embedded in system libc.so.6).
Differential Revision: https://reviews.llvm.org/D74252
This patch skips the AssertFrameRecognizer test for Linux since it appears to
fail on certain distributions (AFAIK Fedora & ArchLinux).
The failure happen because the thread don't set the current frame to
the most relevant one. So the stopped location doesn't match with what
the test is expecting.
The test will be enabled again after I'll be able to reproduce the failure
on one of those platform and fix the issue.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Michał Górny