Re: Undesirable entries in typedefs list

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Undesirable entries in typedefs list
Дата
Msg-id 20180324203655.sf7rhspz4afbv7hx@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Undesirable entries in typedefs list  (Andres Freund <andres@anarazel.de>)
Ответы Re: Undesirable entries in typedefs list  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On 2018-03-24 10:41:40 -0700, Andres Freund wrote:
> I'm about to head out, but afterwards I'm going to check what the
> typedefs collected actually are when LLVM is enabled.

It's indeed from llvm:

 <3><5201>: Abbrev Number: 4 (DW_TAG_typedef)
    <5202>   DW_AT_name        : (indirect string, offset: 0x8a0a4): string
    <5206>   DW_AT_decl_file   : 13
    <5207>   DW_AT_decl_line   : 74
    <5208>   DW_AT_type        : <0x3896>

which basically references std::string

 <3><3896>: Abbrev Number: 24 (DW_TAG_class_type)
    <3897>   DW_AT_name        : (indirect string, offset: 0x2db87): basic_string<char, std::char_traits<char>,
std::allocator<char>>
 
    <389b>   DW_AT_byte_size   : 32
    <389c>   DW_AT_decl_file   : 12
    <389d>   DW_AT_decl_line   : 77
    <389e>   DW_AT_sibling     : <0x51fc>

Given that the PG code shouldn't refer to this, I think we might be able
to limit things by specifying --dwarf-depth=3 to the objdump output.

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.

Greetings,

Andres Freund

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Why does load_external_function() return PGFunction?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PROPOSAL] Shared Ispell dictionaries