Hi Hans,
Been testing on OSX as there is no build or RC3 up on that yet
It appears on Darwin Hosts clang will always invoke gcc even if we specify
a -target to a non Darwin host.
Because of this it completely ignores the Drivers for the other targets
such as MSVC and MINGW.
I'm trying to fix it a
>
> On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev
> wrote:
>
> Slightly related, but do other platforms have a way to check from an inferior
> if a debugger is present?
>
> We need to do this frequently from the test inferiors, and I see lots of
> different approaches used in the
Dear testers,
3.7.0-rc4 has just been tagged. It is identical to rc3, plus:
- r245902: Revert r245355: change of clang-tools-extra symlink in the
release script
- r245947: Merge of r245927: Fix LLDB build on MIPS
- r245948: Deprecate the DataLayout on the TargetMachine, and backport
the 3.8 API
-
On Linux, according to the proc(5) man page, you look at /proc//status.
There's a field "TracerPid" that gives the pid of the tracing process. The
value is 0 if not being traced.
TracerPid: 13849
TracerPid: 0
/proc/pid/stat has a field called "flags" that contains kernel flags, but
There's even a Tech Note for how to do this:
https://developer.apple.com/library/ios/qa/qa1361/_index.html
I think you should be able to see that w/o a developer account, but if you
can't, here's the code:
#include
#include
#include
#include
#include
static bool AmIBeingDebugged(void)
I seem to recall on the Linux side that this gets a bit complicated.
Attaching vs. launching get different sequences of stops, as do the number
of hops through possible shells in between a launch and an attach. So we
pass through a skip-stop count (which I think both OS X and Linux use) to
figure
Assuming we can find a reasonable way to detect this on all platforms, can
I replace current wait-for-debugger-attach code in the test inferiors to
use this method? It's all very racy right now, and there are combinations
of sleeps and loops in the executables sometimes working together with
sleep
There is a way on OS X. There is a sysctl that will give you information on
the current process state, and one of the bits you get back says whether the
process is being traced. sysctl's are a generic UNIX thing, but I don't know
if the bit OS X uses is shared with other Unix's.
Jim
> On Aug
On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to
initiate the attach, and then wait on the pid until it comes back with a
SIGSTOP signal when the attach is completed. How the wait is done differs from
system to system, but this is the general model. I have not he
Posted review here:
http://reviews.llvm.org/D12380
On Wed, Aug 26, 2015 at 2:16 PM, Todd Fiala wrote:
> That seems to be it. I'll spin up a code review for a change to comment
> it out.
>
> On Wed, Aug 26, 2015 at 2:12 PM, Todd Fiala wrote:
>
>> Thanks, Siva. I'll try commenting that out loca
Slightly related, but do other platforms have a way to check from an
inferior if a debugger is present?
We need to do this frequently from the test inferiors, and I see lots of
different approaches used in the test programs, none of which work
correctly on Windows.
On Wed, Aug 26, 2015 at 2:09 PM
That seems to be it. I'll spin up a code review for a change to comment it
out.
On Wed, Aug 26, 2015 at 2:12 PM, Todd Fiala wrote:
> Thanks, Siva. I'll try commenting that out locally and see if that goes
> away.
>
> On Wed, Aug 26, 2015 at 2:11 PM, Siva Chandra
> wrote:
>
>> I see a possible
Thanks, Siva. I'll try commenting that out locally and see if that goes
away.
On Wed, Aug 26, 2015 at 2:11 PM, Siva Chandra
wrote:
> I see a possible printf at DWARFCompileUnit.cpp:444
>
> $> git grep -n ": \[.*-.*)"
> Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:444:
>printf ("0x%8.8x: [0
I see a possible printf at DWARFCompileUnit.cpp:444
$> git grep -n ": \[.*-.*)"
Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:444:
printf ("0x%8.8x: [0x%16.16" PRIx64 " - 0x%16.16" PRIx64 ")\n",
GetOffset(), range.GetRangeBase(), range.GetRangeEnd());
Plugins/SymbolFile/DWARF/DWARFDebugAranges.
On Windows, when we attach to process, we basically invoke a system call
which tells the kernel to kick off the process necessary for a debugger to
be able to communicate with the process.
The end result of all this is that eventually the OS itself will generate a
breakpoint in the inferior by inj
Hi all,
When I run tests with dotest.py -v, I'm seeing a lot of tests spew out
quite a few lines of output that look like an address with some kind of
closed-open range:
e.g.
0x002b0eb4: [0x000facc0 - 0x000face4)
0x002b0f24: [0x000facf0 - 0x000fad11)
0x002b0f94: [
That seems fair. It would be great to have some higher level mechanism to
generate runs of the tests that only differ by how the target programs are
built. For instance, if some day we ever get serious about optimized code
debugging (suppresses giggle) it would be good to run the test suite on
https://llvm.org/bugs/show_bug.cgi?id=24589
Bug ID: 24589
Summary: Target is keeping an open handle to executable during
test runs
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
S
I think I'm goign to abandon this idea for now. Mostly because I've found
a workaround which is a) one line of code and b) only affects windows. So
the impact of this workaround is narrower, no risk of messing up any tests
which depend on cleaning, and gives more time to come up with a more
compr
Not sure if this is relevant, but I seem to recall the remote test
execution would spin off each test method run (test case level, not test
suite level) into a new directory. I don't think that would be inherently
broken by a no-clean scenario but we'd want to make sure it doesn't break.
-Todd
O
I thought of this too and I started prototyping it.
The issue that I ran into is that dsym and dwarf tests can all be xfailed,
skipped, etc for different reasons, so if there is one method body, you
need a way to still define the set of conditions under which dsym and dwarf
tests should run, skip,
On 26 August 2015 at 06:14, Zachary Turner via lldb-dev
wrote:
>
> I'll wait and see if anyone can remember which tests rebuild binaries on
> purpose. Otherwise I will try to look through them and see if I can figure
> it out.
TestInferiorChanged is one that I remember.
I think this is a good t
22 matches
Mail list logo
