debugging C functions
I'm being dim again so can anyone point me to my mistake please?
On a linux system (debian errrr...latest, stable one) and postgresql 7.3.3
Compiling and linking with:
cc -g -fpic -I blah -o blah.o blah.c
ld -g -fpic -shared -o blah.so blah.o
(and trying the link stage with cc instead of ld just on the slim possibility)
Then in psql creating the function with:
create function blah() returns trigger as '/full/path/blah.so', 'blah' language
'C';
and the trigger with:
create trigger blah_trg before insert on blah
for each row execute procedure public.blah();
(The function got created in public by postgres but I then switched user before
creating the trigger and public isn't in it's search_path)
Attaching the debugger to the backend process I can't set a break point on my
function, it says 'Function "blah" not defined' and when it segments somewhere
under SPI_execp called from my function the stack trace has all the postgres
symbols but just a '??' at the place my function is obviously sitting.
nm tells me blah is defined in the text segment as an external symbol and
without any name mangling. The only thing I can see is that asking nm for all
symbols, even the debugging ones, doesn't display anything different to what it
shows without that switch. Now I know this looks like it's not a postgresql
issue but I'd appreciate any pointers you folks can give. This has me baffled.
Thanks
--
Nigel Andrews
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
Attaching the debugger to the backend process I can't set a break
point on my function, it says 'Function "blah" not defined' and when
it segments somewhere under SPI_execp called from my function the
stack trace has all the postgres symbols but just a '??' at the place
my function is obviously sitting.
You won't be able to set a breakpoint in the function if its shared
library hasn't been loaded into the process yet. I'd suggest something
like
<start fresh session>
psql=> LOAD 'libraryname';
<attach to backend with gdb>
gdb> b myfunc
gdb> cont
psql=> SELECT myfunc();
If gdb still claims not to know the function with this approach, you
probably also need to issue a "sharedlibrary" command to gdb to force
it to absorb symbol definitions from the shlib. I think on most
platforms the above sequence will work without that, though.
regards, tom lane
Nigel J. Andrews writes:
Attaching the debugger to the backend process I can't set a break point on my
function, it says 'Function "blah" not defined' and when it segments somewhere
under SPI_execp called from my function the stack trace has all the postgres
symbols but just a '??' at the place my function is obviously sitting.
Use the command LOAD to load the dynamic object into the server process,
then set the break point, then run the function.
--
Peter Eisentraut peter_e@gmx.net
On Fri, 20 Jun 2003, Peter Eisentraut wrote:
Nigel J. Andrews writes:
Attaching the debugger to the backend process I can't set a break point on my
function, it says 'Function "blah" not defined' and when it segments somewhere
under SPI_execp called from my function the stack trace has all the postgres
symbols but just a '??' at the place my function is obviously sitting.Use the command LOAD to load the dynamic object into the server process,
then set the break point, then run the function.
Thanks Peter and Tom. I haven't actually checked that a segmentation fault
lists my function in the stack trace properly (I fixed that fault by code
inspection) however, I had discovered that once the function had run without
faulting the symbols were there. There's too many variables to check properly
now but I had tried using LOAD before and it made no difference but then I
might not have tried the LOAD then attach gdb sequence.
The principal mistake I think was my forgetting that the load isn't done until
the function is first used.
--
Nigel J. Andrews
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
... I might not have tried the LOAD then attach gdb sequence.
I think you need the "sharedlibrary" command to get gdb to know the
symbols in a shlib that was loaded into the process after gdb first
attached to it. If you do the LOAD, then attach, you bypass the need
to issue a manual "sharedlibrary" command.
regards, tom lane