typedefs.list glitches

Started by Tom Laneover 3 years ago4 messages
#1Tom Lane
tgl@sss.pgh.pa.us

I just completed the v15 pre-beta pgindent run. It went reasonably
smoothly, but I had to hack up typedefs.list a little bit compared
to the version downloaded from the buildfarm.

* The buildfarm's list is missing
pg_md5_ctx
pg_sha1_ctx
pg_sha224_ctx
pg_sha256_ctx
pg_sha384_ctx
pg_sha512_ctx
which are certainly used, but only in some src/common files
that are built only in non-OpenSSL builds. So evidently,
every buildfarm member that's contributing to the typedefs list
builds with OpenSSL. That wouldn't surprise me, except that
my own animal sifaka should be filling that gap. Looking at
its latest attempt[1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2022-05-11%2020%3A21%3A15, it seems to be generating an empty list,
which I guess means that our recipe for extracting typedefs
doesn't work on macOS/arm64. I shall investigate.

* The buildfarm's list includes "value_type", which is surely
not typedef'd anywhere in our code, and that is messing up
some formatting involving JsonIsPredicate.value_type.
I suppose that is coming from some system header where it is
a typedef on some machines (komodoensis and lorikeet report it,
which seems like an odd pairing). I think the best thing to
do here is rename that field while we still can, perhaps to
item_type. Thoughts?

regards, tom lane

[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2022-05-11%2020%3A21%3A15

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#1)
1 attachment(s)
Re: typedefs.list glitches

I wrote:

every buildfarm member that's contributing to the typedefs list
builds with OpenSSL. That wouldn't surprise me, except that
my own animal sifaka should be filling that gap. Looking at
its latest attempt[1], it seems to be generating an empty list,
which I guess means that our recipe for extracting typedefs
doesn't work on macOS/arm64. I shall investigate.

Found it. Current macOS produces

$ objdump -W
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: error: unknown argument '-W'

where last year's vintage produced

$ objdump -W
objdump: Unknown command line argument '-W'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump --help'
objdump: Did you mean '-C'?

This confuses run_build.pl into taking the "Linux and sometimes windows"
code path instead of the $using_osx one. I think simplest fix is to
move the $using_osx branch ahead of the heuristic ones, as attached.

regards, tom lane

Attachments:

typedefs.patchtext/x-diff; charset=us-ascii; name=typedefs.patchDownload
--- run_build.pl.orig	2022-01-29 10:18:03.000000000 -0500
+++ run_build.pl	2022-05-12 16:59:58.000000000 -0400
@@ -2163,7 +2163,32 @@ sub find_typedefs
 		next if $bin =~ m!bin/(ipcclean|pltcl_)!;
 		next unless -f $bin;
 		next if -l $bin;    # ignore symlinks to plain files (e.g. postmaster)
-		if (@err == 1)      # Linux and sometimes windows
+		if ($using_osx)
+		{
+			# no run_log due to redirections.
+			@dumpout =
+			  `dwarfdump $bin 2>/dev/null | egrep -A2 TAG_typedef 2>/dev/null`;
+			foreach (@dumpout)
+			{
+				## no critic (RegularExpressions::ProhibitCaptureWithoutTest)
+				@flds = split;
+				if (@flds == 3)
+				{
+					# old format
+					next unless ($flds[0] eq "AT_name(");
+					next unless ($flds[1] =~ m/^"(.*)"$/);
+					$syms{$1} = 1;
+				}
+				elsif (@flds == 2)
+				{
+					# new format
+					next unless ($flds[0] eq "DW_AT_name");
+					next unless ($flds[1] =~ m/^\("(.*)"\)$/);
+					$syms{$1} = 1;
+				}
+			}
+		}
+		elsif (@err == 1)      # Linux and sometimes windows
 		{
 			my $cmd = "$objdump -Wi $bin 2>/dev/null | "
 			  . "egrep -A3 DW_TAG_typedef 2>/dev/null";
@@ -2194,31 +2219,6 @@ sub find_typedefs
 				$syms{ $flds[-1] } = 1;
 			}
 		}
-		elsif ($using_osx)
-		{
-			# no run_log due to redirections.
-			@dumpout =
-			  `dwarfdump $bin 2>/dev/null | egrep -A2 TAG_typedef 2>/dev/null`;
-			foreach (@dumpout)
-			{
-				## no critic (RegularExpressions::ProhibitCaptureWithoutTest)
-				@flds = split;
-				if (@flds == 3)
-				{
-					# old format
-					next unless ($flds[0] eq "AT_name(");
-					next unless ($flds[1] =~ m/^"(.*)"$/);
-					$syms{$1} = 1;
-				}
-				elsif (@flds == 2)
-				{
-					# new format
-					next unless ($flds[0] eq "DW_AT_name");
-					next unless ($flds[1] =~ m/^\("(.*)"\)$/);
-					$syms{$1} = 1;
-				}
-			}
-		}
 		else
 		{
 			# no run_log due to redirections.
#3Tristan Partin
tristan@neon.tech
In reply to: Tom Lane (#2)
Re: typedefs.list glitches

On Thu May 12, 2022 at 4:21 PM CDT, Tom Lane wrote:

I wrote:

every buildfarm member that's contributing to the typedefs list
builds with OpenSSL. That wouldn't surprise me, except that
my own animal sifaka should be filling that gap. Looking at
its latest attempt[1], it seems to be generating an empty list,
which I guess means that our recipe for extracting typedefs
doesn't work on macOS/arm64. I shall investigate.

Found it. Current macOS produces

$ objdump -W
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: error: unknown argument '-W'

where last year's vintage produced

$ objdump -W
objdump: Unknown command line argument '-W'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump --help'
objdump: Did you mean '-C'?

This confuses run_build.pl into taking the "Linux and sometimes windows"
code path instead of the $using_osx one. I think simplest fix is to
move the $using_osx branch ahead of the heuristic ones, as attached.

Hey Tom,

Was this patch ever committed?

--
Tristan Partin
Neon (https://neon.tech)

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tristan Partin (#3)
Re: typedefs.list glitches

"Tristan Partin" <tristan@neon.tech> writes:

Was this patch ever committed?

Yes, though not till

commit dcca861554e90d6395c3c153317b0b0e3841f103
Author: Andrew Dunstan <andrew@dunslane.net>
Date: Sun Jan 15 07:32:50 2023 -0500

Improve typedef logic for MacOS

sifaka is currently generating typedefs, and I'm pretty certain
it's using unpatched REL_17 BF code.

regards, tom lane