Help Resolving Compiler Errors With enable-dtrace Flag

Started by Barry Walkerover 1 year ago9 messagesgeneral
Jump to latest
#1Barry Walker
mstrchef7@gmail.com

Hey folks,

I'm working on a custom version of Postgres that is roughly in line with
16.4 but has customizations in it. I'm trying to compile this custom
version (on Linux) with `--enable-dtrace` but I'm running into an issue
during the linker stage. I've done a clean and full rebuild but that
doesn't help fix the problem. I get these errors for all probes:

access/transam/xact.o(.note.stapsdt+0x24): error: undefined reference
to 'postgresql_transaction__start_semaphore'
access/transam/xact.o(.note.stapsdt+0x78): error: undefined reference
to 'postgresql_transaction__commit_semaphore'
access/transam/xact.o(.note.stapsdt+0xcc): error: undefined reference
to 'postgresql_transaction__abort_semaphore'

I can see the probes.h file gets generated what looks to be correctly,
specifically these:

__extension__ extern unsigned short
postgresql_transaction__commit_semaphore __attribute__ ((unused))
__attribute__ ((section (".probes")));

I have compiled vanilla pg16.4 with the same flags and the probes got
created and linked as expected with no issues so I'm assuming there is some
difference in the custom version that is causing the errors but I'm having
a hard time tracking it down. I'm wondering if anyone here has any
experience with this error or has any hints as to why the linker can't find
these definitions or even just where the actual definitions for these
probes should live so I can try to work backwards and see if there is any
differences in the custom version that is messing with the linker.

Thanks!

#2Adrian Klaver
adrian.klaver@aklaver.com
In reply to: Barry Walker (#1)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

On 10/20/24 09:30, Barry Walker wrote:

Hey folks,

I have compiled vanilla pg16.4 with the same flags and the probes got
created and linked as expected with no issues so I'm assuming there is
some difference in the custom version that is causing the errors but I'm
having a hard time tracking it down. I'm wondering if anyone here has
any experience with this error or has any hints as to why the linker
can't find these definitions or even just where the actual definitions
for these probes should live so I can try to work backwards and see if
there is any differences in the custom version that is messing with
the linker.

Talking to the folks that created the custom version is not possible?

If you do a diff on:

access/transam/xact.o

between the stock and custom version does it shed any light?

Thanks!

--
Adrian Klaver
adrian.klaver@aklaver.com

#3Barry Walker
mstrchef7@gmail.com
In reply to: Adrian Klaver (#2)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

Unfortunately the people remaining are just as lost as me. No one has
attempted to build with dtrace so I'm in uncharted territory.

A diff of the object file doesn't give any useful information, the custom
version has a lot of differences since there have been a number of changes
from stock. postgresql_transaction__commit_semaphore does exist in the
symbol table of both .o files though when compared with objdump.

On Sun, Oct 20, 2024 at 1:50 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

Show quoted text

On 10/20/24 09:30, Barry Walker wrote:

Hey folks,

I have compiled vanilla pg16.4 with the same flags and the probes got
created and linked as expected with no issues so I'm assuming there is
some difference in the custom version that is causing the errors but I'm
having a hard time tracking it down. I'm wondering if anyone here has
any experience with this error or has any hints as to why the linker
can't find these definitions or even just where the actual definitions
for these probes should live so I can try to work backwards and see if
there is any differences in the custom version that is messing with
the linker.

Talking to the folks that created the custom version is not possible?

If you do a diff on:

access/transam/xact.o

between the stock and custom version does it shed any light?

Thanks!

--
Adrian Klaver
adrian.klaver@aklaver.com

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Barry Walker (#1)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

Barry Walker <mstrchef7@gmail.com> writes:

I have compiled vanilla pg16.4 with the same flags and the probes got
created and linked as expected with no issues so I'm assuming there is some
difference in the custom version that is causing the errors but I'm having
a hard time tracking it down. I'm wondering if anyone here has any
experience with this error or has any hints as to why the linker can't find
these definitions or even just where the actual definitions for these
probes should live so I can try to work backwards and see if there is any
differences in the custom version that is messing with the linker.

I'd read

https://www.postgresql.org/docs/current/dynamic-trace.html#DEFINING-TRACE-POINTS

and then go see if those tracepoints are fully conforming to the
coding rules in the modified version. A plausible bet is that
their entries in probes.d don't entirely match up with the calls
in the source code. You could compare the relevant bits of code
between vanilla and modified 16.4 if the problem isn't immediately
obvious.

regards, tom lane

#5Adrian Klaver
adrian.klaver@aklaver.com
In reply to: Barry Walker (#3)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

On 10/20/24 12:02, Barry Walker wrote:

Unfortunately the people remaining are just as lost as me. No one has
attempted to build with dtrace so I'm in uncharted territory.

Was the customization done under version control?

If so then as last resort use bisect or equivalent to find the breaking
change?

A diff of the object file doesn't give any useful information, the
custom version has a lot of differences since there have been a number
of changes from stock. postgresql_transaction__commit_semaphore does
exist in the symbol table of both .o files though when compared with
objdump.

My mistake, was not paying attention. I meant to point the diff at:

~/src/backend/access/transam/xact.c

--
Adrian Klaver
adrian.klaver@aklaver.com

#6Barry Walker
mstrchef7@gmail.com
In reply to: Adrian Klaver (#5)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

Was the customization done under version control?

Yes it was. My thinking though is that I am getting this error with every
probe, not just the ones in xact.c so I suspect there is something more
than just a code change to the file. I compared the common makefiles and
don't see any changes that would cause the linker error. In any case I'll
try to go back through some of the commit history to see if anything stands
out. Thanks for the input!

#7Barry Walker
mstrchef7@gmail.com
In reply to: Tom Lane (#4)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

I'd read

https://www.postgresql.org/docs/current/dynamic-trace.html#DEFINING-TRACE-POINTS

and then go see if those tracepoints are fully conforming to the
coding rules in the modified version. A plausible bet is that
their entries in probes.d don't entirely match up with the calls
in the source code. You could compare the relevant bits of code
between vanilla and modified 16.4 if the problem isn't immediately
obvious.

regards, tom lane

I've taken a look at the probes.d file and there are no changes between the
modified and vanilla versions of the file, and the probes are called with
the same args. This is happening for every probe in the probes.d file.
Since I'm getting those errors it looks like the generated probes.h file is
also properly being used. Do you know where the
postgresql_transaction__commit_semaphore
symbol should be defined?

#8Tom Lane
tgl@sss.pgh.pa.us
In reply to: Barry Walker (#6)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

Barry Walker <mstrchef7@gmail.com> writes:

Yes it was. My thinking though is that I am getting this error with every
probe, not just the ones in xact.c

Now you tell us?

If that's the case, I wonder whether probes.o is getting built
correctly and included in the link. The relevant bits are in
src/backend/Makefile ... they don't look that easy to mess up,
but maybe.

regards, tom lane

#9Barry Walker
mstrchef7@gmail.com
In reply to: Tom Lane (#8)
Re: Help Resolving Compiler Errors With enable-dtrace Flag

Now you tell us?

If that's the case, I wonder whether probes.o is getting built
correctly and included in the link. The relevant bits are in
src/backend/Makefile ... they don't look that easy to mess up,
but maybe.

I thought I mentioned it in my original message but it wasn't super clear.

I just checked and you're right, the probes.o is not getting built for some
reason. I don't even see it attempting to in the build output and when I
add a debug print statement to the utils/probes.o rule I don't see that in
the output. Either way that most certainly explains why I'm getting that
error and gives me something to dig in to more. Thanks for the help!