Re: Undesirable entries in typedefs list
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-03-24T22:07:52Z
Lists: pgsql-hackers
On 2018-03-24 14:51:32 -0700, Peter Geoghegan wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Andres Freund <andres@anarazel.de> wrote: > > I've attached the difference between a objdump typedefs list roughly > > equivalent to what the buildfarm uses. There's no difference when not > > using llvm. > > > > I'm a bit uncomfortable relying --dwarf-depth=3, with 3 being determined > > purely experimentally though. > > A quick look at the DWARF4 standard [1] suggests that this refers to > lexical depth. So, I agree that that doesn't seem like a great idea. > > [1] http://dwarfstd.org/doc/DWARF4.pdf Are you referring to Section 3.4? That's something different afaict. Or which bit are you thinking of? See e.g. https://sourceware.org/bugzilla/show_bug.cgi?id=22250 " Another addition "depth" starts counting from zero. Zero usually is the first DIE (compilation_unit or partial_unit). Specifying --dwarf-depth=0 will only print the Compilation Unit headers, followed by a blank line and no ... markers. Unless --dwarf-depth is given with a non-zero argument, then only a blank line is printed. " My understanding is that it controls through how many levels of nesting in type definitions objdump recurses through. The type of typedefs we really care about are going to be at the global level. Which should make them available at dwarf-depth=2. Then we have a few typedefs which are solely done inside functions, which is why we need dwarf-depth=3. Greetings, Andres Freund
Commits
-
Update pgindent's typedefs blacklist, and make it easier to adjust.
- ef1978d6ed1e 11.0 landed