On 2014-10-08 14:23:44 -0300, Alvaro Herrera wrote: > Robert Haas wrote: > > On Wed, Oct 8, 2014 at 8:47 AM, Andres Freund <and...@2ndquadrant.com> > > wrote: > > > I don't see that as being relevant. The difference is an instruction or > > > two - in the slow path we'll enter the kernel and sleep. This doesn't > > > matter in comparison. > > > And the code is *so* much more readable. > > > > I find the slist/dlist stuff actually quite difficult to get right > > compared to a hand-rolled linked list. But the really big problem is > > that the debugger can't do anything useful with it. You have to work > > out the structure-member offset in order to walk the list and manually > > cast to char *, adjust the pointer, and cast back. That sucks. > > As far as I recall you can get gdb to understand those pointer games > by defining some structs or macros. Maybe we can improve by documenting > this.
So, what makes it work for me (among other unrelated stuff) seems to be the following in .gdbinit, defineing away some things that gdb doesn't handle: macro define __builtin_offsetof(T, F) ((int) &(((T *) 0)->F)) macro define __extension__ macro define AssertVariableIsOfTypeMacro(x, y) ((void)0) Additionally I have "-ggdb -g3" in CFLAGS. That way gdb knows about postgres' macros. At least if you're in the right scope. As an example, the following works: (gdb) p dlist_is_empty(&BackendList) ? NULL : dlist_head_element(Backend, elem, &BackendList) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers