Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
On Wed, 2014-04-23 at 08:49 -0400, Frank Ch. Eigler wrote: > Hi - > > On Wed, Apr 23, 2014 at 01:46:30PM +0200, Mark Wielaard wrote: > > [...] > > > > So if a producer wants to take advantage of a default location list > > > > entry to encode a smaller location list for an object, then how should > > > > it present to the consumer the same "not available" information? > > > > > > I think that this is an unusual situation. Can you describe when this > > > might be the case? > > > > I think it is not such an uncommon situation. When a compiler inlines > > part of a function somewhere else that often seems to create interesting > > ranges and locations. [...] > > It sounds like the situation for gcc's -g -O0 (unoptimized) case, > where a default location is emitted for a variable DIEs, but that > location is only valid/accurate outside the prologue/epiogue areas. > (The pc-address ranges of those areas are not noted in DWARF, and this > requires consumers like gdb & systemtap to employ heuristics.) Yes, it is a bit like that. Except since a default entry is used in a location list there are also valid ranges that don't need any heuristics. And for the consumer it might not be clear whether to use any heuristics or whether they can just rely on complete information provided by the producer using fixups to indicate the invalid ranges like suggested by Michael. The trick is to make sure producers and consumers agree on the interpretation of the valid ranges. Cheers, Mark ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
Hi Michael, On Wed, 2014-04-23 at 06:54 -0700, Michael Eager wrote: > On 04/23/14 04:46, Mark Wielaard wrote: > >> An alternate might be to include a location list entry for the range > >> where the object is not available and have that contain a zero-length > >> location list. That would be non-standard, but I think that any > >> consumer would reasonable interpret this as location not available. > > > > That could work. It just needs a bit more work on the producer side to > > know whether using a default location entry plus filling in "the > > gaps" (and start and end range) results in a smaller location list. > > Could that be made into "standard behavior" and recommended as best > > practice when using a default location entries? > > The best practice is to use the default location list entry as it was > intended and as documented. I don't think that is a very useful way to document the best practice. If it was perfectly clear what the intention of the producer and interpretation of the consumer was when using a default location list entry then we wouldn't be having this conversation :) I do like you suggestion to make the producer be able to provide complete range information for the location list that uses a default entry and would be happy to work on wording a proposal that would make that into something standard. It would also be good to have some examples of location lists using default entries that clearly convey the intention of the producer and how to interpret them by the consumer. Thanks, Mark ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Interaction between aranges and unit proposals
Hi Tom, On Wed, 2014-04-23 at 09:01 -0600, Tom Tromey wrote: > Mark> To make it possible to quickly see whether an address (range) is covered > Mark> by an ELF file containing DWARF information two proposals were made: > > I finally read through this thread. > > Cary> I think it's fine for a consumer to first assume that the > Cary> .debug_aranges table is complete, but if an address lookup fails, then > Cary> it can scan the .debug_info section, hopping from one CU/TU to the > Cary> next, looking for CUs that aren't covered by .debug_aranges tables. > Cary> Having the debug_info length field in the aranges table would help, > Cary> but even then, it's not clear to me how much it will help. > > The idea was to avoid having to scan all the CUs just because a bad > address was given. > > However, the completeness property is probably more important for > by-name indices, where you don't want a single typo to destroy whatever > performance gain you get from an index. That depends on whether you assume bad addresses won't normally happen and won't cause regeneration of the index. Sadly it seems that while debugging (seeing a bad or unitialized function pointer), or sometimes even when trying to produce a simple backtrace (you'll need the DWARF info to show inlines) you do often get addresses that might point to something random. What do you do then if you cannot rely on the completeness or correctness of the aranges table? > That said, on the whole I think it's probably fine to drop this > proposal. While this remains a bit of a hole in DWARF, in practice we > run dwz on everything in the distro and it can fix up issues like this. I don't think that is a good idea. dwz is a really great tool. But it only works for "production" debug info. It won't be used for the common edit-compile-debug cycle of your program that isn't packaged and in production yet. When used as a DWARF compressor that just represent the same information just in a smaller way I think dwz is perfect. But if users would need to run it to fix up the produced DWARF then I think we are better off fixing the original DWARF producers. What I am really trying to avoid is having to ship duplicate aranges information. Once in standard DWARF .debug_aranges and then again (but more complete) in .gdb_index. If that is necessary to efficiently use GDB then I feel we need to fix the .debug_aranges specification. Thanks, Mark ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Default Location List Entry Issue 130121.1
On 04/24/14 01:38, Mark Wielaard wrote: Hi Michael, On Wed, 2014-04-23 at 06:54 -0700, Michael Eager wrote: On 04/23/14 04:46, Mark Wielaard wrote: An alternate might be to include a location list entry for the range where the object is not available and have that contain a zero-length location list. That would be non-standard, but I think that any consumer would reasonable interpret this as location not available. That could work. It just needs a bit more work on the producer side to know whether using a default location entry plus filling in "the gaps" (and start and end range) results in a smaller location list. Could that be made into "standard behavior" and recommended as best practice when using a default location entries? The best practice is to use the default location list entry as it was intended and as documented. I don't think that is a very useful way to document the best practice. If it was perfectly clear what the intention of the producer and interpretation of the consumer was when using a default location list entry then we wouldn't be having this conversation :) We will review the entire document before we publish a public review draft. We will keep your comments in mind when we look at this section. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About self-referencial sized types
On 04/23/2014 04:34 PM, Tom Tromey wrote: Jakub> That's strange, for Fortran arrays GCC emits DW_OP_push_object_address Jakub> heavily. AFAICT it's never come "seriously" to anybody's attention. Looking for more information about DW_OP_push_object_address, I found a thread from 2007[1] in which Jan Kratochvil submits patches for VLAs handling on the gdb-patches@ mailing list, including support for this operation. It seems that these patches were never pushed, though[2]. As Joel said, today we have VLAs handling in GDB, but not this specific hunk. [1] https://sourceware.org/ml/gdb-patches/2007-11/msg00321.html [2] https://sourceware.org/ml/gdb/2011-03/msg00021.html -- Pierre-Marie de Rodat ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About self-referencial sized types
On 04/23/2014 04:14 PM, Tom Tromey wrote: Just to address the gdb part -- the only reason this isn't implemented is that presumably no gdb developer has ever encountered a compiler that emits it. It shouldn't be hard to add should you need it. Please file a bug in gdb bugzilla. As a matter of fact, I'm working on GCC, and specifically on the part that emits DW_OP_push_object_address operations (as Jakub said). Still, I know nothing about Fortran yet, so I'm not able to file a proper bug report. Besides, I would not be able to say what I expect GDB to do when provided a DW_OP_push_object_address... hence my question in this thread. ;-) -- Pierre-Marie de Rodat ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
