This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, May 11, 2009 at 6:12 AM, Pedro Alves <pedro@codesourcery.com> wrote: >> handle = dlopen (library, RTLD_NOW); > > I wonder if making this RTLD_LAZY until you found the correct one > wouldn't make sense? I don't believe so. AFAICT, the reason for RTLD_NOW is to make sure that this libthread_db is really compatible with this GDB (doesn't require any symbols GDB doesn't provide); and also to prevent GDB from dying half way through with "unable to resolve symbol ...". Both of these still apply to whatever the "final" libthread_db is going to be. Why would we want to dlopen(... RTLD_LAZY) and try to initialize libthread_db if we are going to reject it as unusable in the end? >> +static int >> +thread_db_load_search () > > ? ? ? ? ? ? ? ? ? ? ? ? ^ (void) Fixed, thanks. > ?(this function could be made to use `openat' at some point, but > ? gdb is already assumes PATH_MAX is largest path possible elsewhere > ? anyway) > > I also wonder if `set sysroot' should affect this search path: I think > not, but I'm not 100% sure. I don't believe it makes sense for 'set sysroot' to affect this search path. >> +int libpthread_name_p (const char *name) >> +{ > > ? ? ?^ function name at column 0, please. Fixed, thanks. Anxiously waiting for Daniel's verdict now ... -- Paul Pluzhnikov
Attachment:
gdb-thread-db.20090511.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |