search for: stmt_list

...dev. Bottom line, > we may need a target specific patch for targets that do not follow dwarf > standard (as per my reading) in this particular case. Hi Devang, Ok, got the background, but will reply on this email. As far as I understood, there is nothing wrong with the way clang deals with stmt_list. The encoding is correct (AFAIK) and the offsets are always zero in every object file, as there is only one line table and one debug_info. The problem is during link time. GCC also generated zero for stmt_list in the objects but links correctly in the end. I still haven't figured out which typ...

...follow dwarf standard (as per my reading) in this particular case. - Devang On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at systemcall.org>wrote: > Hi, > > I'm trying to compile two files together with debug information but > seems that LLVM is getting the DW_AT_stmt_list wrong when ld is > linking the final executable. > > Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object > files, the DW_AT_stmt_list were null, as expected. When linking, they > should point to the offset in the line table, but all of them are > still null, so poi...

...out type > units to MC as soon as they're done. It should be relatively non-intrusive > (we build type units once, there's no ambiguity about when they're done) - > for non-fission+type units it might be a bit tricky, because the type units > still need a relocation for the stmt_list* (I'm trying to find where that's > added now... I seem to have lost it), but fission+type units should produce > entirely static type units that are knowable the moment the type is being > emitted so far as I can tell (including the type hash and everything - you > can write th...

...ast lookup of CUs and TUs. Likely I'll start with: * adding llvm-dwarfdump support for the DWP indexes * basic prototype of llvm-dwp just concatenating sections * handle each of the domain specific relocations in turn * abbr_offset * debug_str_offsets.dwo entries * type_unit's DW_AT_stmt_list * references to debug_loc.dwo from debug_info.dwo * this one, at first blush, makes me particularly sad, as it'll involve actually walking all the DIEs in any CUs (stmt_list isn't great either, but at least that'd only be the header - same for accessing the signature for the CU,...

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 25 August 2010 18:54, Devang Pate...

Hi, I'm trying to compile two files together with debug information but seems that LLVM is getting the DW_AT_stmt_list wrong when ld is linking the final executable. Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object files, the DW_AT_stmt_list were null, as expected. When linking, they should point to the offset in the line table, but all of them are still null, so pointing all to the same line ta...

...t; >> * adding llvm-dwarfdump support for the DWP indexes >> * basic prototype of llvm-dwp just concatenating sections >> * handle each of the domain specific relocations in turn >> * abbr_offset >> * debug_str_offsets.dwo entries >> * type_unit's DW_AT_stmt_list >> * references to debug_loc.dwo from debug_info.dwo >> * this one, at first blush, makes me particularly sad, as it'll >> involve actually walking all the DIEs in any CUs (stmt_list isn't great >> either, but at least that'd only be the header - same for...

...(: ) -> $$ = nterm match_stmt (: ) Stack now 0 1 15 10 44 Entering state 199 Reducing stack by rule 129 (line 1271): $1 = nterm match_stmt (: ) -> $$ = nterm stmt (: ) Stack now 0 1 15 10 44 Entering state 186 Reducing stack by rule 126 (line 1257): $1 = nterm stmt (: ) -> $$ = nterm stmt_list (: ) Stack now 0 1 15 10 44 Entering state 185 Next token is token "colon" (: ) Reducing stack by rule 123 (line 1235): -> $$ = nterm comment_spec (: ) Stack now 0 1 15 10 44 185 Entering state 420 Reducing stack by rule 125 (line 1244): $1 = nterm stmt_list (: ) $2 = nterm comme...

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

On 25 Aug 2010, at 23:11, Renato Golin wrote: > As far as I understood, there is nothing wrong with the way clang > deals with stmt_list. The encoding is correct (AFAIK) and the offsets > are always zero in every object file, as there is only one line table > and one debug_info. Are you taking into account the relocation information? Use "objdump - Dr" on an the object file compiled by gcc -gdwarf-2, and you will s...

...(: ) -> $$ = nterm match_stmt (: ) Stack now 0 1 19 12 59 Entering state 316 Reducing stack by rule 282 (line 2072): $1 = nterm match_stmt (: ) -> $$ = nterm stmt (: ) Stack now 0 1 19 12 59 Entering state 288 Reducing stack by rule 279 (line 2058): $1 = nterm stmt (: ) -> $$ = nterm stmt_list (: ) Stack now 0 1 19 12 59 Entering state 287 Reading a token: --accepting rule at line 611 (" ") Next token is token "newline" (: ) Reducing stack by rule 278 (line 2046): $1 = nterm stmt_list (: ) -> $$ = nterm rule_alloc (: ) Stack now 0 1 19 12 59 Entering state 286 N...