search for: sharedlibrari

Hello lldb developers, I am running into a problem with lldb on Linux. I am currently running llvm 6.0.0. I have an executable that dynamically loads a large number of shared libraries at runtime. These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen. If I

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be surfaced to the user (unless you have the stop-on-sharedlibrary-events setting set, which you

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Hi Nick, --start-group/--end-group functionality with the Gnu flavor currently works only if the --start-group/--end-group contains archive files. If they contain dynamic libraries, the undefined atoms from the dynamic libraries are processed whenever the group is iterated again. I am trying to find out a way to make the resolver add undefined atoms from the shared library only *once*, when

I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic libraries (or regular object files) only once even if they are in

I've run into some issues with the current atom object model that I would like to fix. The current 4 atoms are not expressive enough. We need to be able to serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

Hi, We are rebasing our audio compression subsystem using OPUS rather than SPEEX. The platform is Android but this piece is written in C code: we need to support armv5/armv7/x86 architectures.... and we use the released opus-1.1beta package from here<http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz>. A lot of our OPUS build system + code to drive the audio compression has been

Hi Rui, I thought about this, but there is a catch. The undefined symbols still need to be resolved with exports from dynamic libraries even the second time, or any number of times. For example :- ld 1.o --start-group libc.so myprintf.a --end-group 1.o has a undef for myprintf, which is in myprintf.a and myprintf.a calls puts. The first time when libc.so, undef atoms would be added, no

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able to >>>