similar to: [assembler + debuginfo] interaction with .file directive and debuginfo

What does gcc do? On Fri, Aug 24, 2018 at 9:05 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > There are two forms of the .file directive. One is simply > > .file "path" > > and the other is > > .file <file-number> [ "dir"] "path" [ …. other stuff ] > > > > The latter is sometimes

I think that absolute atoms will need something similar to, "contentType" added. SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a contentType method to AbsoluteAtom and sprinkled changes around to

Hi Nick, The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. I dont think the linker has to add a absolute symbol by figuring out the translation unit. Shankar Easwaran On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: >

On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: > > I think that absolute atoms will need something similar to, "contentType" added. > > SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a

On 10/15/12 12:01, Nick Kledzik wrote: > > On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >> >> I think that absolute atoms will need something similar to, "contentType" added. >> >> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type

On Oct 15, 2012, at 9:06 PM, Shankar Kalpathi Easwaran wrote: > The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. > > I dont think the linker has to add a absolute symbol by figuring out the translation unit. Then we are in agreement. Sid started this thread with the suggestion of adding new content

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

On Thu, Jan 10, 2013 at 4:42 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Well, I saw the .debug_info.dwo stuff (though I didn’t realize it was so > recent), but it wasn’t clear to me how adding a map for a section with a > different purpose would work -- that is, whether it should be yet another > member variable in DWARFContextInMemory or if there was some better

On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: > On 10/15/12 12:01, Nick Kledzik wrote: >> >> On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >>> >>> I think that absolute atoms will need something similar to, "contentType" added. >>> >>> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order

On Thu, Jan 10, 2013 at 3:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Actually, MCJIT doesn’t perform relocations on debug sections. I’m not > sure that would matter anyway. The place where I’m handling the debug > information is outside MCJIT and the MCJIT relocation code isn’t really > accessible at that point.**** > > ** > I know it doesn't,

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5

I have read ELF specification once again. There is no any explicit references to absolute symbols with no name. The only real case when I see such symbol is a local absolute symbol with "STT_FILE" type. The name of "STT_FILE" symbol is a name of the source file associated with the object file and the "STT_FILE" symbol precedes the other STB_LOCAL symbols from this

Well, I saw the .debug_info.dwo stuff (though I didn't realize it was so recent), but it wasn't clear to me how adding a map for a section with a different purpose would work -- that is, whether it should be yet another member variable in DWARFContextInMemory or if there was some better way to combine them. It also wasn't clear to me what the relocation map was doing anyway and what

Actually, MCJIT doesn't perform relocations on debug sections. I'm not sure that would matter anyway. The place where I'm handling the debug information is outside MCJIT and the MCJIT relocation code isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing

Hi, Method RefNameBuilder::buildDuplicateNameMap() has an assert which blocks atoms with empty name. In general it looks reasonable but some toolchains (for example Sourcery CodeBench in both MIPS and ARM editions) can generate an object file contains absolute STT_FILE symbols with empty name. Moreover crt1.o object file from this toolchain has such symbol. I do not know is it a feature or bug

Adam, The test case was the Python-3.6.0b3 release, 234 input YAML files. The large majority of time is spent with processing the file input. Next ranked was rendering output. Moving the files to a tmpfs partition didn’t change the time significantly (but I would expect that experiment would yield different results with libYAML). original, single-threaded: processed input files

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features but

On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > From: David Blaikie <dblaikie at gmail.com> > >> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto: > paul.robinson at sony.com> wrote: > >> There are many bits of DWARF-5 that haven’t been implemented. > > > > Got a short list, by chance? > > I

Hello all, it looks like we have a bug here but I am not sure. Currently if we have two similar types with implicit_const attributes and different values we end up with only one abbrev in .debug_abbrev section. For example consider two structures: S1 with implicit_const attribute ATTR and value VAL1 and S2 with implicit_const ATTR and value VAL2. The .debug_abbrev section will contain only 1