similar to: RFC - a proposal to support additional symbol metadata in ELF object files in the ARM compiler

Hi Peter, Thanks for the response. If we set aside the discussion of the relationship between sections and the application of the "location" or "at" attribute for a moment, do you have any objections to the proposed method of encoding metadata information about symbols (whether they are associated with actual data objects, functions, or sections) in the ELF object file?

Hi Snider. As you and Peter mentioned there are indeed toolchains that allow location placement from within the C/C++ source code, using attributes or similar. I always wonder if such extension is worth the effort. There are downsides like the non-standard ways of communicating this information to the linker, different places that control location of things (linker and compiler sources). I would

On Wed, 1 May 2019 at 15:03, Finkel, Hal J. <hfinkel at anl.gov> wrote: > > On 5/1/19 7:22 AM, Christof Douma via llvm-dev wrote: > > Hi Snider. > > > > As you and Peter mentioned there are indeed toolchains that allow location placement from within the C/C++ source code, using attributes or similar. I always wonder if such extension is worth the effort. There are

James, What you are doing below is tricking the compiler into believing that it is dealing with a real int object that has actual space allocated to it in x2.o, but sym is not defined as a real data object in x1.o Thanks, but that doesn’t really address my use case. I still contend that associating a placement address with an actual data object (whether it be initialized or not) or function,

I have the same question as James has. It seems to me that you can name any address using an absolute symbol, and that should suffice to handle memory-mapped peripherals and such. If you really need to define data (whether it's in .data or .bss) or a function at a fixed memory address, that's not something you can do with absolute symbols (but you can do with linker scripts), but is this

*From: *Snider, Todd <t-snider at ti.com> *Date: *Thu, May 9, 2019 at 3:53 AM *To: *Rui Ueyama, James Y Knight *Cc: *llvm-dev > > James, Rui, > > > > If we are only talking about addressable hardware registers, peripherals, > etc., then the absolute address symbol is one way to facilitate access to a > symbol associated with a specific address. > > > >

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

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 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 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

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

This adds [f]getc() and fgets() for parsing config files. Probably hard to avoid. Still trying to decide if I actually want to add system() or not. -hpa

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

2012/1/23 Bendersky, Eli <eli.bendersky at intel.com>: > Hi, > > I would like to examine the implications you mention in more detail. > Thank you! > (1) Symbol address > According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, > st_value is an offset from the

Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset()

Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's

Hi, I am new to llvm, not familiar with c++, after some use with llvm-objdump, and finding the broken output, I try to debug and fix the code so it can become usable. Please help review the patch, so that they can be merged. And there's still two major problem I have found about arm disassembler: 1. arm instruction decoder cannot recognise bx series instructions. 2. As gcc will

On Tue, Oct 11, 2011 at 12:15 AM, Neo <smtian at ingenic.cn> wrote: > Hi, >    I am new to llvm, not familiar with c++, after some use with > llvm-objdump, and finding the broken output, I try to debug and fix the code > so it can become usable. Please help review the patch, so that they can be > merged. >    And there's still two major problem I have found about arm

Hi Greg, I'm afraid I've not looked into the infrastructure Jim put into place, so I've not really been able to answer the "how should I do it" questions, but hopefully I can comment on the ABI. > And probably questions for Tim, are these "section-relative" mapping > symbols, as defined in 4.6.5.1 of the ELF for ARM document? Yes, they are. > And what

As discussed in the high-level ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), we would like to add support for native object wrapped bitcode and ThinLTO information. Based on comments on the mailing list, I am adding support for ThinLTO in both normal bitcode files, as well as native-object wrapped bitcode. The following RFC describes the planned file format of