similar to: [LLVMdev] DWARF unmangled subprog name (DW_AT_name)

That doesn't seem possible with the public API or am I mistaking? On Wed, May 7, 2014 at 12:13 AM, Eric Christopher <echristo at gmail.com>wrote: > On Tue, May 6, 2014 at 8:09 PM, Isaiah Norton <isaiah.norton at gmail.com> > wrote: > > Hi, > > > > I am looking for a way to get unmangled subprogram names from a > > DWARFContext. The name I want is

The use case is getting the short name for backtraces. There are other options, but I figured it was worth a shot trying to access from the DWARF structure because what we need is already stored there anyway. Thanks, Isaiah On Wed, May 7, 2014 at 12:24 PM, Alexey Samsonov <samsonov at google.com>wrote: > Yeah, public API of DebugInfo library is quite minimalistic. But I agree >

On Wed, May 7, 2014 at 11:33 AM, Eric Christopher <echristo at gmail.com>wrote: > Have you checked out llvm-symbolize? It's what the asan folk > (including Alexey) have created for backtrace symbolication. > Yeah, we potentially can add some kind of option: "llvm-symbolizer -print-short-function-names", I don't yet see why this would be valuable. What's wrong

On Wed, May 7, 2014 at 11:38 AM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The use case for this is in Julia backtraces. We don't have a consistent > way to mangle the function names for linkage (we might at some point in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access

Hi, To use DTrace on some C++ code, I found that Apple''s implementation had another option "-xmangled". Its usage could be found here: http://blog.mozilla.com/dmandelin/2008/02/14/dtrace-c-mysteries-solved/ And it could be found in Apple''s man page: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/dtrace.1.html Is it possible to have that

Hi Chen, On Jul 8, 2011, at 11:56 AM, kobe James wrote: > Hi All, > > I hope to get some information about functions in a bitcode file. Say, if we have a function foo(), and the bitcode file is generated by a single source file, then I want to get the line number foo() locates in that source file. > If the bitcode file is linked by multiple bitcode files, is it possible to also get

We're inconsistent about using DW_AT_MIPS_linkage_name versus DW_AT_linkage_name. Variables (see DwarfCompileUnit::getOrCreateGlobalVariableDIE()) get the standard attribute for DWARF >= 4, MIPS for older. Subprograms (see DwarfUnit::applySubprogramDefinitionAttributes()) always get DW_AT_MIPS_linkage_name (no version check). Before I go drudging through however many tests will die if I

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i

On Feb 11, 2012, at 7:51 AM, Yuri Pankov <yuri.pankov at gmail.com> wrote: > Hi, > > ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: > die 141: base type without name). Is it intended behavior? Not that I know of, please file a bug. Thanks! -eric

Hi All, I hope to get some information about functions in a bitcode file. Say, if we have a function foo(), and the bitcode file is generated by a single source file, then I want to get the line number foo() locates in that source file. If the bitcode file is linked by multiple bitcode files, is it possible to also get which file foo() locates in? Thanks, Chen -------------- next part

[This is something like a bug report; maybe somewhat longish & technical ..] As an introduction, just try the following code (it should work both in R and S). I think it screws up the postscript() driver both for S and R, but this is not the issue here. is.R <- function() { ## returns 'TRUE' iff we are using 'R' exists("version") && !is.null(vl

Hello, I'm trying to fix a long standing issue we are having in Julia where when the file information switched, we weren't recording that correctly, so line information showed up in the wrong file. Basically we would always create a scope with the DISubprogram and the given line number. What I tried was to change the scope to be a DIFile instead so we'd get the correct file

Sorry, I didn't have a small IR example and I was sure I was just doing something stupid. Thanks for the help, I'll try it out and report back. Maybe it would be good to add an assertion or something that tells people what's wrong in this case, since the generated DWARF seems to be invalid? On Wed, Aug 13, 2014 at 5:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > Use

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded

Hi Frédéric and LLVM, I managed to finally come back to this after quite a while. Frédéric, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a

Hi, Chris (cc) and I try to get the SGE master monitor work with Apple Leopard dtrace. Unfortunately we are stuck with the error msg below. Anyone having an idea what could be the cause? What I can rule out as cause is function inlining for the reasons explained below. Background information on SGE master monitor implementation is under http://wiki.gridengine.info/wiki/index.php/Dtrace

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

I hope this time I'm using the "iris" dataset correctly: ir <- rbind(iris3[,,1], iris3[,,2], iris3[,,3]) lir <- data.frame(log(ir)) names(lir) <- c("a","b","c","d") I'm trying to understand the meaning of expressions like "~ a+b+c+d", used with princomp, e.g. princomp(~ a+b+c+d, data=lir, cor=T) By inspection, it