c++ "file" - How to set breakpoints on future shared libraries with a command flag

no defined (4)

OT: In terminal it would look like this to debug Caja in one line:

gdb -ex "set breakpoint pending on" -ex "break gdk_x_error" -ex run --args caja --sync

I'm trying to automate a gdb session using the --command flag. I'm trying to set a breakpoint on a function in a shared library (the Unix equivalent of a DLL) . My cmds.gdb looks like this:

set args /home/shlomi/conf/bugs/kde/font-break.txt
b IA__FcFontMatch

However, I'm getting the following:

shlomi:~/progs/bugs-external/kde/font-breaking$ gdb --command=cmds.gdb...
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
(no debugging symbols found)
Function "IA__FcFontMatch" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]

So it doesn't set the breakpoint after all. How can I make it default to answer "y" to set breakpoints on pending future shared library load?

I recall that I was able to do something, but cannot recall what.

With no symbols.

objdump -t /lib/libacl.so
no symbols
objdump -T /lib/libacl.so
00002bd0 g    DF .text  000000d0  ACL_1.0     acl_delete_entry

(gdb) break 0x0002bd0 

(gdb) x/20i acl_delete_entry
0x2bd0 <acl_delete_entry>:      stwu    r1,-32(r1)
0x2bd4 <acl_delete_entry+4>:    mflr    r0
0x2bd8 <acl_delete_entry+8>:    stw     r29,20(r1)
0x2bdc <acl_delete_entry+12>:   stw     r30,24(r1)
0x2be0 <acl_delete_entry+16>:   mr      r29,r4
0x2be4 <acl_delete_entry+20>:   li      r4,28972

Replying to myself, I'd like to give the answer that someone gave me on IRC:

(gdb) apropos pending
actions -- Specify the actions to be taken at a tracepoint
set breakpoint -- Breakpoint specific settings
set breakpoint pending -- Set debugger's behavior regarding pending breakpoints
show breakpoint -- Breakpoint specific settings
show breakpoint pending -- Show debugger's behavior regarding pending breakpoints

And so set breakpoint pending on does the trick; it is used in cmds.gdb like e.g.

set breakpoint pending on
break <source file name>:<line number>

I would rewrite your dequeue function as:

std::string FileQueue::dequeue(const std::chrono::milliseconds& timeout)
    std::unique_lock<std::mutex> lock(qMutex);
    while(q.empty()) {
        if (populatedNotifier.wait_for(lock, timeout) == std::cv_status::timeout ) 
           return std::string();
    std::string ret = q.front();
    return ret;

It is shorter and does not have duplicate code like your did. Only issue it may wait longer that timeout. To prevent that you would need to remember start time before loop, check for timeout and adjust wait time accordingly. Or specify absolute time on wait condition.

c++ c linux unix gdb