Displaying 20 results from an estimated 7000 matches similar to: "Missing symbol __executable_start on Android when linking with LLD"
2017 May 30
2
Missing symbol __executable_start on Android when linking with LLD
Android libc casts its address to the elf header type. So I think start of text?
Rafael Avila de Espindola <rafael.espindola at gmail.com> schreef op 30 mei 2017 20:51:19 CEST:
>It is missing from lld.
>
>Do you know what it should point to? The first executable PT_LOAD?
>
>Thanks,
>Rafael
>
>Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
2017 Feb 21
3
[lld] elf linker creates undefined empty symbol
Hi,
When running my own lld generated library/executable I'm getting:
LD_LIBRARY_PATH=. ./ConsoleApplication347
./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347:
undefined symbol:
(theres nothing after undefined symbol)
How can I figure out what's I'm doing wrong?
Full log:
https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656
readelf -s for
2017 Feb 22
2
[lld] elf linker creates undefined empty symbol
Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177
The attached foo.diff adds a print which shows the issue.
```
NAME: sleep SYMINDEX: 2
NAME: sched_yield SYMINDEX: 1
NAME: __libc_start_main SYMINDEX: 0
```
`readelf --relocs` Shows that we create :
...
000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410
__xstat at GLIBC_2.2.5 + 0
000000255118 001e00000007
2016 Nov 27
3
llvm optimizer turning musttail into tail
r287955 seems like it might be related.
-- Sean Silva
On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com> wrote:
> This sounds buggy to me. What pass is doing this?
>
> -- Sean Silva
>
> On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> I've got some calls like:
>>
2017 Feb 22
2
[lld] elf linker creates undefined empty symbol
On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Carlo Kok <ck at remobjects.com> writes:
>
> > On 2017-02-21 20:33, Rafael Avila de Espindola wrote:
> >>> Input files:
> >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0
> >>
> >> If you pass --reproduce
2017 Sep 19
1
Interleaved debug info on arm
> On Sep 18, 2017, at 10:13 PM, Carlo Kok <ck at remobjects.com> wrote:
>
> September 18, 2017 8:17 PM, "Adrian Prantl" <aprantl at apple.com> wrote:
>
>> Have you tried looking at the --dump-after-all output to see which pass (if any) is adding the
>> extra line table entries?
>> -- adrian
>
>
> You mean --print-after-all ? I
2014 Sep 15
2
[LLVMdev] codeview debug info in Visual Studio
Hi Carlo,
Do you have VS2010 handy? It should read the DI fine.
Unfortunately, VS2013 is not able to use the debug info we generate.
It is on my plans to investigate and fix the generator, but I didn't have
enough free cycles recently.
--
Tim
2014-09-15 20:30 GMT+04:00 Reid Kleckner <rnk at google.com>:
> +Timur
>
> Hm, this didn't work out of the box for me.
>
>
2017 Feb 21
3
[lld] elf linker creates undefined empty symbol
On 2017-02-21 20:33, Rafael Avila de Espindola wrote:
>> Input files:
>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0
>
> If you pass --reproduce foo.tar to lld it will create a foo.tar file
> with all that is needed to reproduce the link.
>
> Can you also share how you created the various .o files? If so I might
> be able to try reducing the issue.
2018 Mar 21
0
lld/lto/win32 crash on DIE code
Yep, it's once again variable and it's type using different scopes.
Is there any strong reason why you set scope for global DIDerivedType?
________________________________________
От: Carlo Kok <ck at remobjects.com>
Отправлено: 21 марта 2018 г. 18:22
Кому: Evgeny Leviant; llvm-dev at lists.llvm.org
Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code
Thanks!
Unfortunately this
2016 Dec 22
0
debug info "ref" parameter
I think probably the simplest answer is that dbg.declare documents that it
must point to an alloca ("This intrinsic provides information about a local
element (e.g., variable). The first argument is metadata holding the alloca
for the variable. ") - so it's probably best not to think too hard about
what it does when that criteria is not met.
2016 Nov 24
3
llvm optimizer turning musttail into tail
I've got some calls like:
musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to void
(i32, i8*)*)(i32 %0, i8* %1)
ret void
Into something like:
%8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null)
ret void
I realize I'm losing a parameter there, but this is an interface jump
trick I use and relies on the end code being a 'jmp' (x86). I realize i
can probably
2014 Sep 15
2
[LLVMdev] codeview debug info in Visual Studio
Hi,
Is there any way to debug the codeview output of llvm from within Visual
Studio?
I want to use the codeview line info debug output of clang/llvm. I tried
with the
x86_64-pc-windows-msvc and i686-pc-windows-msvc triples and linking it
into an
existing project with VC++ from within the IDE and outside with link
/debug.
Neither option lets me debug with Visual Studio as debugger host.
2014 Sep 15
2
[LLVMdev] codeview debug info in Visual Studio
On Mon, 15 Sep 2014 19:33:42 +0200, Timur Iskhodzhanov
<timurrrr at google.com> wrote:
> Basically, see my patches to LLVM from early 2014 -- they include tests,
> a DI generator and a DI dumper. I'd be happy to review your patches too!
Thanks. Looks like it's likely that it's one of the 0xF1 sections, the
first one always has the object file name and what seems
2016 Jun 01
2
linkonce_odr & coff
I have @_rtti_a_a = linkonce_odr constant in two files that end up as
coff object files. Shoudln't the linkonce_odr prevent duplicate symbol:
__rtti_a_a \consoleapplication149.o and __rtti_a_a island.lib(island.o)
from happening in LLD?
If not what alternative can I use? THis is used for template like
generics, so having duplicate functions and globals is going to happen a
lot)
(Side
2018 Mar 21
3
lld/lto/win32 crash on DIE code
Thanks!
Unfortunately this doesn't seem to cause it, because when I fix it to
match the other files (and pretty much how clang emits it:)
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName:
"f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope:
!2, file: !3, type: !622, isLocal:
2017 Apr 26
2
no-frame-pointer-elim & optimized
Hi,
I have a function with:
attributes #2 = { "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" }
Yet when compiling it generates:
https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3
(Note how it checks fFinalizer before setting up ebp).
It also has a:
.loc 36 195 7 prologue_end
before this happens
How can I get llvm to do the frame
2016 Dec 22
2
debug info "ref" parameter
On 2016-12-22 19:02, David Blaikie wrote:
> if you could simplify it down a bit, that might be helpful - not sure
> there's a lot to be gained - I imagine it is just a quirk of how we
> handle these things in the backend to make normal debug info work, but
> there might be some things to be done to help.
>
That's my guess too, special behavior when it sees an alloca.
2017 Sep 18
5
Interleaved debug info on arm
When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all
over the place:
...
0x00000000000595ac 22 11 1 0 0 is_stmt
0x00000000000595bc 25 7 1 0 0 is_stmt <<<
0x00000000000595c0 22 11 1 0 0 is_stmt
0x00000000000595c4 25 7 1 0 0 is_stmt <<<
0x00000000000595c8 26 7 1 0 0 is_stmt
but the code only has 1 reference to line 25 and the
2017 Apr 26
2
no-frame-pointer-elim & optimized
On 2017-04-26 19:56, Eric Christopher wrote:
> That's really weird. I'm quite surprised that the entry block was moved
> so much later in the function but haven't had a chance to look more at
> it. Probably want to take a look and find out where that's happening and
> why.
From irc, thegameg helped me find the -enable-shrink-wrap=false, which
"fixes" this,
2016 Oct 19
2
Assertion fail/crash in X86FrameLowering::GetFrameIndexReference SEH
I think r262546 introduced the assumption that allocas are used exactly
once with catchpad. It seems easy to fix, though.
On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> This turned out to be related to reusing the local used in the catchpad,
> for example given the following c++ code:
>
> extern void rthrow();
>
> int