similar to: Linker option to dump dependency graph

On Wed, Feb 27, 2019 at 1:37 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Tue, Feb 26, 2019 at 2:24 PM Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I've heard people say that they want to analyze dependencies between >> object files at the linker level so that they can run a whole-program

On Tue, Feb 26, 2019 at 3:31 PM Michael Spencer <bigcheesegs at gmail.com> wrote: > On Tue, Feb 26, 2019 at 2:23 PM Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I've heard people say that they want to analyze dependencies between >> object files at the linker level so that they can run a whole-program >>

Hello, I think outputting a dependency graph is a good idea and would enable some offline analysis. I think that there is some advantage to building some of the simpler ones in, particularly those that would need heavy annotations to the dependency graph, in particular unless we write a sample analysis tool that ships with the release, many users are going to miss out on useful features as they

+1 for graphviz dot format, so that it can be consumed by any one of many existing graph visualization tools. On Wed, Feb 27, 2019 at 7:29 PM Shi, Steven via llvm-dev < llvm-dev at lists.llvm.org> wrote: > >To summarise, I think we may > > be able to do quite well with some very simple extra analysis in LLD, > > a machine readable dependency graph would also be very

You might have realized this already but it's probably not a good idea to use InputSection::Relocations for this because that ends up missing anything that becomes a dynamic relocation. I reckon that the code should be doing exactly what MarkLive.cpp is doing. Peter On Thu, Feb 28, 2019 at 5:15 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I hacked up a patch to

Just wanted to check in on this - did your patches make it past the prototype phase? On Tue, Mar 5, 2019 at 2:41 AM Fāng-ruì Sòng via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > One thing a dependency graph might not capture is the order in which > events occur, this can be very useful when debugging problems caused by > library selection order. > > The event stream

Sorry, I didn't notice that you are asking not to me but to Fangrui. Please disregard my previous email. On Fri, Jun 21, 2019 at 9:08 PM Rui Ueyama <ruiu at google.com> wrote: > No I didn't. > > On Fri, Jun 21, 2019 at 10:52 AM Andrew Grieve via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just wanted to check in on this - did your patches make it

Hi, Many linkers including lld have a feature to eliminate unused sections from output to make output smaller (which is essentially a mark-sweep gc where sections are vertices and relocations are edges). lld and GNU gold have yet another feature, ICF, to merge functions by contents to save more space. When we remove or merge a function, we want to eliminate its exception handling information as

No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers

Hi, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused

Yes, it's a little bit off-topic, but it is also planned. The data structure that the linker handles can be considered a large graph where vertices are file sections and edges are symbol names. You can say that file A depends on file B if and only if in the graph a section in file A has an edge to a section in file B. There is a plan to dump the graph in a machine-readable format such as JSON

>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make >sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by >default. I'll start investigating the

Yeah, I think there's no reason to not add this to lld/COFF if people find it useful. On Wed, Jul 31, 2019 at 10:25 AM Shi, Steven <steven.shi at intel.com> wrote: > I love this feature. Does it plan to support COFF as well? > > > > > > Thanks > > Steven > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Rui >

On Thu, Jun 15, 2017 at 11:09 AM, Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 15, 2017 at 10:55 AM, Michael Spencer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Thu, Jun 15, 2017 at 10:08 AM, Tobias Edler von Koch < >> tobias at codeaurora.org> wrote: >> >>> Hi Michael,

On Nov 1, 2011, at 6:26 PM, Michael Spencer wrote: > A major feature of the linker design I have been working on is the > object file IR it is based on. It takes the concept of an atom (a > named range of data) and formalizes it into a graph based data > structure where edges represent the relations between atoms such as > relocations, groupings, and layout constraints. This

On Thu, Jun 15, 2017 at 2:33 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Thu, Jun 15, 2017 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Thu, Jun 15, 2017 at 11:09 AM, Xinliang David Li via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Jun

On Thu, Jun 15, 2017 at 10:08 AM, Tobias Edler von Koch < tobias at codeaurora.org> wrote: > Hi Michael, > > This is cool stuff, thanks for sharing! > > On 06/15/2017 11:51 AM, Michael Spencer via llvm-dev wrote: > >> The first is a new llvm pass which uses branch frequency info to get >> counts for each call instruction and then adds a module flags metatdata

Hi llvm-dev, I'm currently looking for alternatives to the synthetic references that XRay uses to keep some side-tables live, to avoid linker garbage collection from deleting those sections. Before going any further, let me give a backgrounder on what XRay does today. Background ========== XRay has two side tables we use at runtime to identify the location of the sleds for the functions

I was wondering if anyone has a way out of the limitation that you must use equal length x,y, and z sequence lengths. For instance, x<-seq(1,100) y<-seq(1,100) z<-rnorm(100) scatterplot3d(z,x,y) works fine. However, if I get some results that has a different y subset length, such as x<-seq(1,100) y<-seq(1,300) z<-rnorm(100) scatterplot3d(z,x,y) I get the following error:

I was searching for the code could be factored out for a dependency analyzer. The one written by Tanya for SparcV9. The machine code dependency is necessary for some architecture which the (efficient) instruction scheduling could not be possible without the register allocation is done first. For example, the VLIW machines (most DSP's are). For an efficient instruction scheduling, the