> On Oct 14, 2015, at 4:04 PM, Ryan Brown wrote:
>
> Well the go linker is actually what generates code from the IR, so it's
> always required. And as it stands now you can cross compile from another
> platform as long as you don't link with c code. I don't know if they'd want
> to change tha
Well the go linker is actually what generates code from the IR, so it's
always required. And as it stands now you can cross compile from another
platform as long as you don't link with c code. I don't know if they'd want
to change that by always using the os x linker. I filed a bug for them to
add
I just did a fresh svn clone, but I can't get it to build in xcode.
It seems to be failing because it can't find something for ios. Is there
some way to make it skip the ios stuff?
...
llvm[3]: Copying runtime library darwin/profile_osx to build dir
cp
/Users/ribrdb/Documents/git/lldb/llvm-build
Glad we identified your problem. Can you guys always use the system linker? Any
reason to use another linker? If you continue to a custom linker you will want
to modify it to set these. If you compile Go programs that run on iOS simulator
or iOS you will want to emit a LC_MIN_VERSION_IOS.
Greg
Yep, it looks like LC_VERSION_MIN_MACOSX is missing.
target list shows:
target #0: /private/tmp/gopath/bin/wikilinktester ( arch=x86_64-apple-,
platform=host )
specifying --arch doesn't seem to work. It still has the modules loaded
starting at 0, and target list says:
* target #1: /tmp/gopath/bin
> On Oct 14, 2015, at 1:02 PM, Joerg Sonnenberger via lldb-dev
> wrote:
>
> On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote:
>> EH frame can't be used to unwind when we are in the first frame because
>> it is only valid at call sites. It also can't be used in frames th
Hi Tamas,
There is an assert in DWARFDIE.cpp (lines 189 - 191) that we're hitting on
the OS X side somewhat frequently nowadays:
assert ((id&0xull) == 0 ||
(cu_id&0xll) == 0 ||
(id&0xull) == (cu_
On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote:
> EH frame can't be used to unwind when we are in the first frame because
> it is only valid at call sites. It also can't be used in frames that
> are asynchronously interrupted like signal handler frames.
This is not neces
I am guessing that your binary is missing a LC_VERSION_MIN_XXX load command and
so it is being loaded with "-unknown-unknown" as the architecture. This
is probably causing LLDB to load the DynamicLoaderStatic as the dynamic loader
which just loads all shared libraries as the address that is cont
EH frame can't be used to unwind when we are in the first frame because it is
only valid at call sites. It also can't be used in frames that are
asynchronously interrupted like signal handler frames. So at frame zero, we
typically just fall back to the default unwind plan for the current
archit
I have the same behavior with the system lldb and the one I build in xcode.
My xcode is Version 6.4 (6E35b)
I just hit command-b to build, is that what you mean? I don't really know
xcode very well.
On Tue, Oct 13, 2015 at 10:08 PM Todd Fiala wrote:
> > Breakpoint 1: where = wikilinktester`main
On Tue, Oct 13, 2015 at 9:08 PM Todd Fiala wrote:
> On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner
> wrote:
>
>> On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner
>> wrote:
>>
>>> Moving this to the public list because it seems useful to see what other
>>> members of the community have to say as
Thanks for an excellent explanation.
Unfortunately, -fno-limit-debug-info did not fix the problem; and that
I don't see the problem with a gcc/gdb setup.
So what I'm doing is forward-declaring LLVM IR entities (like `Value',
`Type', `Function'), so that multiple downstream modules don't include
t
https://llvm.org/bugs/show_bug.cgi?id=25147
lab...@google.com changed:
What|Removed |Added
Assignee|lldb-dev@lists.llvm.org |lab...@google.com
--- Comment #2 from lab...
https://llvm.org/bugs/show_bug.cgi?id=25172
Bug ID: 25172
Summary: TestBatchMode is flaky on linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority:
Hi
As far as I know, if the unwinding based on Assembly Instruction
Profiling fails in LLDB then either EH frame unwinding or some other
mechanism comes into picture to unwind properly. Am I right?
In this case, should LLDB change the unwinder plan from Assembly
Instruction Profiling to EH Frame
16 matches
Mail list logo
