[lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()
Greg et al: When linking (cmake on OS X), I get a lot of warnings like this: ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder() from lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o) Should this function be in the public namespace? It is an inline function which is why I think it gets flagged as hidden. Can we move it out of the lldb namespace? Or has that ship sailed? Is there some other way that we can suppress this warning or fix the underlying issue? (Can we exclude a symbol from being exported somehow?) This isn't the only symbol that is a problem, but it is the one that generates the most output. - Bruce ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB expressions confused by overloading
I believe I have tracked down an interesting bug which related to LLDBs expression parser. In my target program I have a math library, a shared object which makes use of clangs __attribute__((overloadable)) extension for C99. This causes the the function names in the math library to be mangled. A problem arises however since some of the function names mirror those exported by libm.so, and the function names in libm are not mangled. My problem scenario: If I call an expression during a debugging session, the symbol table of libm.so is consulted first and a match will be found. Later on in the expression setup, any dwarf information will be consulted for functions with this name. libm.so doesn't have any debugging info attached, however the math library of my target may. In this case the expression will now call which ever function it could first find dwarf info for, regardless of the name mangling. The net result is that a function will be called in my targets math library that may not match the given function signature. In my case this causes the expression to raise a SEGFAULT and fail. I was seeing an expression to call a vector4 function, in fact call the vector 2 version behinds the scenes. One solution to this problem seems to be to have the expression evaluator try and first look for any functions that may have a mangled name for the given function signature, and if that fails fall back to simply checking for the unmangled version, as is currently done. Would this make sense? It seems less then ideal to have a clash of mangled and unmangled names, but I can imagine this situation may not be all that rare. I am happy to provide more info if it would be usefull. Thanks, Aidan -- Aidan Dodds staff software engineer, Debuggers Codeplay Software Ltd Level C, Argyle House, 3 Lady Lawson St. Edinbrgh, EH3 9DR Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com Twitter: https://twitter.com/codeplaysoft This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. Company registered in England and Wales, number: 04567874 Registered office: 81 Linkfield Street, Redhill RH1 6BY ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()
> On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev > wrote: > > Greg et al: > > When linking (cmake on OS X), I get a lot of warnings like this: > > ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder() > from > lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o) > > Should this function be in the public namespace? No I don't believe it should. > It is an inline function which is why I think it gets flagged as hidden. > > Can we move it out of the lldb namespace? Or has that ship sailed? Is there > some other way that we can suppress this warning or fix the underlying issue? > (Can we exclude a symbol from being exported somehow?) Please feel free to move it to the lldb_private namespace. Nothing in our lldb/API/SB* header files should use it, so it is fine to move it. Let me know if you run into any troubles doing so. > This isn't the only symbol that is a problem, but it is the one that > generates the most output. We should have no inlined functions in our public API if we can avoid it. That is a sure way to have people crash if we ever change anything and they linked against the inline code from the header file. Greg Clayton ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB expressions confused by overloading
On Thu, Nov 5, 2015 at 9:43 AM, Aidan Dodds via lldb-dev wrote: > I believe I have tracked down an interesting bug which related to LLDBs > expression parser. > > In my target program I have a math library, a shared object which makes use > of clangs __attribute__((overloadable)) extension for C99. This causes the > the function names in the math library to be mangled. > A problem arises however since some of the function names mirror those > exported by libm.so, and the function names in libm are not mangled. > > My problem scenario: > If I call an expression during a debugging session, the symbol table of > libm.so is consulted first and a match will be found. Later on in the > expression setup, any dwarf information will be consulted for functions with > this name. libm.so doesn't have any debugging info attached, however the > math library of my target may. In this case the expression will now call > which ever function it could first find dwarf info for, regardless of the > name mangling. > > The net result is that a function will be called in my targets math library > that may not match the given function signature. In my case this causes the > expression to raise a SEGFAULT and fail. I was seeing an expression to call > a vector4 function, in fact call the vector 2 version behinds the scenes. > > One solution to this problem seems to be to have the expression evaluator > try and first look for any functions that may have a mangled name for the > given function signature, and if that fails fall back to simply checking for > the unmangled version, as is currently done. Is this similar to the problem tackled by this patch: http://reviews.llvm.org/D12809 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Reminder: LLVM bay-area social is tonight @7PM
It's the first thursday of the month, and like every month, we have a social! 7pm at Tied House as usual. http://www.meetup.com/LLVM-Bay-Area-Social/events/226134792/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 22875] unwind-on-error-in-expressions=false is broken
https://llvm.org/bugs/show_bug.cgi?id=22875 Keno Fischer changed: What|Removed |Added Status|NEW |RESOLVED CC||kfisc...@college.harvard.ed ||u Resolution|--- |FIXED --- Comment #1 from Keno Fischer --- Fixed in Clang by r252229. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()
On Fri, Nov 6, 2015 at 1:00 AM, Greg Clayton wrote: > > > On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Greg et al: > > > > When linking (cmake on OS X), I get a lot of warnings like this: > > > > ld: warning: cannot export hidden symbol > lldb::endian::InlHostByteOrder() > > from > lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o) > > > > Should this function be in the public namespace? > > No I don't believe it should. > > > It is an inline function which is why I think it gets flagged as hidden. > > > > Can we move it out of the lldb namespace? Or has that ship sailed? Is > there some other way that we can suppress this warning or fix the > underlying issue? (Can we exclude a symbol from being exported somehow?) > > Please feel free to move it to the lldb_private namespace. Nothing in our > lldb/API/SB* header files should use it, so it is fine to move it. Let me > know if you run into any troubles doing so. Review: http://reviews.llvm.org/D14417 > > This isn't the only symbol that is a problem, but it is the one that > generates the most output. > > We should have no inlined functions in our public API if we can avoid it. > That is a sure way to have people crash if we ever change anything and they > linked against the inline code from the header file. > After fixing this one, the remaining cases are: ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAttachInfo.cpp.o ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from tools/lldb/source/API/CMakeFiles/liblldb.dir/SBLaunchInfo.cpp.o ld: warning: cannot export hidden symbol lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o ld: warning: cannot export hidden symbol lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o ld: warning: cannot export hidden symbol lldb::SBPlatform::operator=(lldb::SBPlatform const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBQueueItem::operator=(lldb::SBQueueItem const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBQueueItem::SBQueueItem(lldb::SBQueueItem const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBQueueItem::SBQueueItem(lldb::SBQueueItem const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBLaunchInfo::SBLaunchInfo(lldb::SBLaunchInfo const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o ld: warning: cannot export hidden symbol lldb::SBLaunchInfo::SBLaunchInfo(lldb::SBLaunchInfo const&) from tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o - Bruce ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
