search for: lineinfo

...uot; > +#include "llvm/Support/FileSystem.h" > +#include "llvm/Support/Mutex.h" > +#include "llvm/Support/MutexGuard.h" > +#include "llvm/Support/raw_ostream.h" > + > +using namespace llvm; > +using namespace llvm::object; > +typedef DILineInfoSpecifier::FileLineInfoKind FileLineInfoKind; > + > +namespace { > + > +// language identifier (XXX: should we generate something better from debug info?) > +#define JIT_LANG "llvm-IR" > +#define LLVM_PERF_JIT_MAGIC ((uint32_t) 'J' << 24 | (uint32_t) 'i&...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

...m, so that they get dead stripped or coalesced as a group (that is what ld64 does). > Do you mean typeCode atoms here ? Yes, eh frames are used in ELF. The eh_frame sections have to be first read to make this happen, so that function atoms may point to their respective FDE block. >>> b) LineInfo >> This was an experiment in ld64. At one point we thought it might be nice when erroring out with undefined symbol to give the source file and line number of each use of the undefined symbol. But that never panned out. > This might be a good thing to have it in lld too, would be easy to...

..., g.gl_matchc); + globfree(&g); + if (tmp != NULL && strlen(tmp) > strlen(file)) { + if (el_insertstr(el, tmp + strlen(file)) == -1) + fatal("el_insertstr failed."); + xfree(tmp); + } + return (g.gl_matchc); +} + +unsigned char +complete(EditLine *el, int ch) +{ + const LineInfo *lf; + size_t len, pos; + char *line; + int argc = 0, ap_loc = 0, ap_cur = 0; + #define MAXARG 99 + char **ap, *argv[MAXARG]; + + ch = ch; /* not used */ + lf = el_line(el); + len = lf->lastchar - lf->buffer + 1; + line = (char *)malloc(len); + strlcpy(line, lf->buffer, len)...

...len--; + if (el_insertstr(el, "\\ ") == -1) + fatal("el_insertstr failed."); + } + } + } + + xfree(tmp); + } + + return (g.gl_matchc); +} + +unsigned char +complete(EditLine *el, int ch) +{ + char **argv, *line; + u_int x, argc, carg, len, ret = CC_ERROR; + const LineInfo *lf; + + lf = el_line(el); + + /* Figure out which argument we are on */ + len = lf->cursor - lf->buffer + 1; + line = (char *)xmalloc(len); + strlcpy(line, lf->buffer, len); + argv = makeargv(line, &carg); + xfree(line); + + /* now get the real argument */ + len = lf->lastchar - lf...

Hi, In a 32-bit ARM build, I am seeing the following warning (edited for simplicity, I can provide full logs if necessary): > llvm-objdump -l -d -x file.elf > llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf All object files and static libraries seem to have debug info (i.e., llvm-objdump does not complain when run on each file individually and