On Wed, Nov 27, 2013 at 9:44 PM, Ian Lance Taylor <i...@google.com> wrote:
> On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov <samso...@google.com> wrote:
>>
>> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
>> standard tells that compilation unit entries "may have" attributes
>> specifying the
>> address range, but doesn't tell they are obligatory.
>> DWARF consumers probably shouldn't rely on their presence.
>
> How are consumers of LLVM debug info expected to determine the address
> range of the function?Sorry, I wasn't clear enough. GCC emits DW_AT_low_pc and DW_AT_high_pc for *compile unit* DIE, so the consumer doesn't have to iterate over all the functions DIEs. LLVM doesn't emit DW_AT_low_pc/DW_AT_high_pc for compile unit, but emits them for function DIEs. I've added some debugging output to libbacktrace and noticed it was able to build [address range]->[compile unit] mapping only for sources compiled with GCC, so I suggested that it doesn't examine all the descendants of compile unit DIEs to build the ranges. > Is the intent that the consumer should assume > that the function continues from the DW_AT_low_pc address to the next > DW_AT_low_pc address from the debug info? Or should the consumer look > at the function size from the symbol table? Or should the consumer > examine all the DIEs looking for address ranges? > > Does LLVM support anything like GCC's -freorder-blocks-and-partition > option, and, if so, how does it represent the address ranges in the > debug info? > > Ian -- Alexey Samsonov, MSK
