similar to: Tree conflict on 'include/llvm/DebugInfo/Msf and lib/DebugInfo/Msf

Hi all, If you don't care about Debug Info or PDB files you can stop reading now. Just wanted to give a heads up that I'm planning to add a new folder under DebugInfo called Msf. MSF stands for Multi-Stream File and is the container format used by PDB debug info files. However, MSF by itself is generic enough that it need not contain PDB data, and in fact I can think of at least one

I actually regret doing all caps for PDB, and there seems to be mixed use of all caps / rolling caps even with dwarf (some places say DWARF, others say Dwarf). I don't feel too strongly aside from the minor inconvenience of having to change thousands of occurrences where I already used rolling caps though :-/ On Fri, Jul 22, 2016 at 10:52 AM Reid Kleckner <rnk at google.com> wrote:

The bot has been failing its CMake step for a while now. Probably fallout from renaming Msf to MSF. Can somebody get this straightened out? It's one of the bots that run VS2013 AFAICT which makes it useful to me. Thanks, --paulr

The latter. Unfortunately we need to get physical access and delete the checkout. I'm afraid reverting will just reintroduce the problem and re-break all the bots that people already took the time to fix, since going from MSF -> Msf is the same as going from Msf -> MSF On Mon, Aug 1, 2016 at 8:55 AM Reid Kleckner <rnk at google.com> wrote: > So, the MSF rename managed to break

Some background: A while back while working on code to read / write PDB files, I came up with Yet Another Stream Abstraction. Note that LLVM already has a few. Off the top of my head, theres: 1) `MemoryBuffer` and its associated class hierarchy 2) `raw_ostream` and it's associated classes. 3) `DataExtractor` which is used for reading from a StringRef. There's probably more, and

On Tue, Jul 26, 2016 at 8:02 AM, Reid Kleckner <rnk at google.com> wrote: > We've been pursuing the direction of writing PDBs from scratch in > llvm/lib/DebugInfo/PDB/Raw and related directories. It might be interesting > to have code that talks to MSPDB140.dll in LLVM, but we really want LLD to > be able to produce its output on any platform. > I completely agree

Hello, GCC 9.0 introduces a new warning checkers and some of them found possible issues in LLVM. In file included from /home/davidbolvansky/trunk/llvm/include/llvm/Analysis/LazyCallGraph.h:38, from /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:10: /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of

On Tue, Jul 26, 2016 at 12:30 PM, Zachary Turner <zturner at google.com> wrote: > I wrote most of the pdb code in llvm so far. As Reid suggested, if you > look in DebugInfo/PDB/Raw there is a significant amount of code dealing > with msf files and raw pdb streams. If you build the llvm-pdbdump tool you > can run it with the "raw" subcommand to dump lots of low level

> On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com> wrote: > > I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. > > There's still more to be done on the pdb dumping tool, but at this

>The pdb reading code relies *very heavily* on Windows APIs can you make shure not to have any windows api stuff in the pdb-reader interface so its easy to - if someone wants to - implement an windows-api independent version (support reading under linux etc.) because the pdb format needs to be analysed anyway for writing pdb information on compile/link (in the future) Am 29.01.2015 um 19:20

On Thu Jan 29 2015 at 10:22:17 AM Zachary Turner <zturner at google.com> wrote: > I've been working on adding pdb reading support to llvm. This started as > a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has > been checked in and currently has limited support for dumping pdb. > > There's still more to be done on the pdb dumping tool, but at

> On Jan 29, 2015, at 11:08 AM, Zachary Turner <zturner at google.com> wrote: > > See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional

> On Jan 29, 2015, at 10:24 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu Jan 29 2015 at 10:22:17 AM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote: > I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been

See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. Does

Haven't got to this but would like to take a look/review it before it goes in. *skimming over some of the description* Sounds like 'stream' might not be the right terminology - since they return pointers into data that (I think) remains valid for the life of the stream? (this also makes me wonder a bit about memory usage if the cross-block operation is used a lot (causing

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic

Hi, I have a CentOS 6.4 fileserver running SerNet Samba 4.0.9 with these global settings (not overridden): read only = No force create mode = 0777 force directory mode = 0777 inherit acls = yes inherit owner = yes inherit permissions = yes On a Windows client, I have Thunderbird 24.0 storing its profile and mail on the Samba share. The

Hi, Even though I am not running a centos.plus kernel yum wants to install the kernel-debuginfo for it. # yum install --disablerepo=\* --enablerepo=base-debuginfo kernel-debuginfo Loaded plugins: fastestmirror, refresh-packagekit Setting up Install Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package kernel-debuginfo.x86_64

Hello all, According to [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64: "Debuginfo packages are also being signed and pushed. Yum configs shipped in the new release file will have all the context required for debuginfo to be available on every CentOS Linux install." Specifically, I'm looking for kernel-debuginfo-3.10.0-229.1.2.el7.x86_64, but the latest debuginfo

Hi! On C7 I enabled the debuginfo repo and ran: debuginfo-install glibc-2.17-55.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.11.3-49.el7.x86_64 libcom_err-1.42.9-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.1e-34.el7_0.4.x86_64 pcre-8.32-12.el7.x86_64 xz-libs-5.1.2-8alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64 Loaded plugins: fastestmirror, langpacks Loading mirror speeds