Re: Undesirable entries in typedefs list - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Undesirable entries in typedefs list
Date
Msg-id 20180324220752.7p6uazp2qmhihs5t@alap3.anarazel.de
Whole thread Raw
In response to Re: Undesirable entries in typedefs list  (Peter Geoghegan <pg@bowt.ie>)
List 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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Undesirable entries in typedefs list
Next
From: Peter Geoghegan
Date:
Subject: Re: WIP: Covering + unique indexes.