Re: format_datum debugging function - Mailing list pgsql-hackers

On 8/14/24 02:16, Peter Eisentraut wrote:
> On 12.08.24 23:15, Paul Jungwirth wrote:
>> On 8/12/24 04:32, Aleksander Alekseev wrote:
>>>> [...] This function takes a Datum and the appropriate out function, and returns a char *. So you
>>>> can do this:
>>>>
>>>> (gdb) call format_datum(range_out, $1)
>>>> $2 = 0x59162692d938 "[1,4)"
>>>>
>>>> I assume a patch like this doesn't need documentation. Does it need a test? Anything else?
>>>
>>> I think you forgot to attach the patch. Or is it just a proposal?
>>
>> Sorry, patch attached here.
> 
> I don't think it's safe to call output functions at arbitrary points from a debugger.  But if you're 
> okay with that during development, say, then I think you could just call 
> OidOutputFunctionCall(F_RANGE_OUT, $1)?

I assumed it wasn't safe everywhere (e.g. there is potentially a TOAST lookup), but for debugging a 
patch that's okay with me.

Are you doing something to get macro expansion? I've never gotten my gdb to see #defines, although 
in theory this configure line should do it, right?:

./configure 'CFLAGS=-ggdb -Og -g3 -fno-omit-frame-pointer' --enable-tap-tests --enable-cassert 
--enable-debug --prefix=${HOME}/local

I also tried -gdwarf and -gdwarf-4 and -gdwarf-5 (all still with -Og -g3).

If it makes a difference, I'm attaching to a process:

paul@tal:~/src/postgresql$ gdb -p 1175735
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 1175735
Reading symbols from /home/paul/local/bin/postgres...
Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libz.so.1)
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/a5/08ec5d8bf12fb7fd08204e0f87518e5cd0b102.debug...
Reading symbols from /lib/x86_64-linux-gnu/libicui18n.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicui18n.so.70)
Reading symbols from /lib/x86_64-linux-gnu/libicuuc.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicuuc.so.70)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug...
Reading symbols from /lib/x86_64-linux-gnu/libstdc++.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libstdc++.so.6)
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libgcc_s.so.1)
Reading symbols from /lib/x86_64-linux-gnu/libicudata.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicudata.so.70)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000079878e325dea in epoll_wait (epfd=7, events=0x573f0e475820, maxevents=1, timeout=-1) at 
../sysdeps/unix/sysv/linux/epoll_wait.c:30
30      ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
(gdb) b range_in
Breakpoint 1 at 0x573f0d9b5042: file rangetypes.c, line 91.
(gdb) c
Continuing.

Breakpoint 1, range_in (fcinfo=0x7fff6d8fea90) at rangetypes.c:91
91      {
(gdb) fin
Run till exit from #0  range_in (fcinfo=0x7fff6d8fea90) at rangetypes.c:91
0x0000573f0da8c87e in InputFunctionCall (flinfo=0x7fff6d8feb20, str=0x573f0e47a258 "[3,5)", 
typioparam=3904, typmod=-1) at fmgr.c:1547
1547            result = FunctionCallInvoke(fcinfo);
Value returned is $1 = 95928334988456
(gdb) call OidOutputFunctionCall(F_RANGE_OUT, $1)
No symbol "F_RANGE_OUT" in current context.

If I know the oid, then this works:

(gdb) call OidOutputFunctionCall(3835, $1)
$2 = 0x5f9be16ca4d8 "[3,5)"

That is a big improvement, but still a little annoying.

Thanks,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com