Обсуждение: 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