On 6/6/22 1:59 AM, David Faure wrote:
That's an artefact of your debugging technique, due to a not very well known feature of shared libraries called (PLT Procedure Linkage Table).After doing dprintf QGraphicsScene::update, "QGraphicsScene::update\n" if you ask gdb for its breakpoints, you'll see that this matched two locations: (gdb) info br Num Type Disp Enb Address What 2 dprintf keep y <MULTIPLE> breakpoint already hit 411 times printf "QGraphicsScene::update\n" 2.1 y 0x00007ffff6b71a66 in QGraphicsScene::update(QRectF const&) at qtbase/src/widgets/graphicsview/qgraphicsscene.cpp:3213 2.2 y 0x00007ffff722a950 <QGraphicsScene::update(QRectF const&)@plt> The second one (@plt) is a thin wrapper over the first one, to implement Position Independent Code.
Thanks for the explanation. I'm familiar with the GDB "N.1, N.2, ..." "sub-breakpoints", although usually with inlined methods and on ARM which is where I do most of my low-level debugging. And although I've worked with PIC, DSOs, lazy binding, etc. I'd never gone down into the PLT/GOT details.
The question in https://stackoverflow.com/questions/70589450/why-functions-in-same-shared-library-using-plt explains this better than I would:
Thanks for the education. Chasing down some long chains of links from the above provides a lot of casual reading material. ;)
Executive summary: QGraphicsScene::update() is called only once in practice, in your scenario.
One mystery solved. More ahead, as per your next post. _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
