similar to: [LLVMdev] [llvm-commits] Atom alignment

Initial issue is related to R_MIPS_GPREL16/32 relocations. When we calculate such relocations we need to know _gp symbol's value. This value might come from different sources. Usually we setup it using constant offset from the .got section. Also it might be defined by a linker script. And in rare but possible case it comes from .reginfo / .MIPS.options sections. Got example, GNU bfd linker

On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > So I was looking into handling ELF groups today in the Atom model. It > appears that we will need to add the concept of a group to the atom > model directly, as modeling it with references fails to capture some > semantics. > > http://www.sco.com/developers/gabi/latest/ch4.sheader.html > > Groups in ELF are

On Dec 19, 2012, at 4:53 PM, Michael Spencer wrote: > On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: >>> So I was looking into handling ELF groups today in the Atom model. It >>> appears that we will need to add the concept of a group to the atom >>> model

I support Nick's option too. I think handling groups is another example of using follow on references. One question is how does an atom outside the group refer to the main atom here ? Will not garbage collection cleanup the main atom/signature atom because there are no references ? Thanks - Shankar Easwaran On Wed, Dec 19, 2012 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote:

On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > >> So I was looking into handling ELF groups today in the Atom model. It >> appears that we will need to add the concept of a group to the atom >> model directly, as modeling it with references fails to capture some >>

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able to >>>

Sent from my iPhone On Mar 9, 2013, at 1:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/8/2013 5:44 PM, Nick Kledzik wrote: >> On Mar 8, 2013, at 2:52 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >>> Hi Nick, >>> >>> I was looking at ld64 source code and the atom deals with additional information such as

Thanks, Shankar. I needed to override all the places where st_value had been used, and it worked. But there another problem appeared: after correcting all atoms, I cannot distinguish between ARM and Thumb symbols in the further stages when fixing up relocations. I used to check targetVAddress (in terms of the relocation handler) since it contained 1 in the least bit when addressing Thumb

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Tuesday, November 17, 2020 1:51 AM > To: Alexander Yermolovich <ayermolo at fb.com> > Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson

You are right. LLD does not have this problem. Initially I bumped into the MIPS specific bug related to GP relative relocations calculation. I tried to make reproduction script as general as possible and mistakenly make it too general. So now with your help I realized that the problem solely affects MIPS. On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org> wrote: >

I've run into some issues with the current atom object model that I would like to fix. The current 4 atoms are not expressive enough. We need to be able to serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

So I was looking into handling ELF groups today in the Atom model. It appears that we will need to add the concept of a group to the atom model directly, as modeling it with references fails to capture some semantics. http://www.sco.com/developers/gabi/latest/ch4.sheader.html Groups in ELF are collections of sections that must be either included or excluded as a unit. They also are used to

On 10/30/2013 12:53 AM, Nick Kledzik wrote: > On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: >> I am trying to implement support for handling section groups in lld. >> >> There are two ways of figuring out section groups with ELF. >> >> a) Sections with SHF_GROUP property >> b) .gnu.linkonce sections (the signature identified by the name of the section)

On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: > I am trying to implement support for handling section groups in lld. > > There are two ways of figuring out section groups with ELF. > > a) Sections with SHF_GROUP property > b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. > >

Hi Nick, I am trying to implement support for handling section groups in lld. There are two ways of figuring out section groups with ELF. a) Sections with SHF_GROUP property b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is

On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> At Sony we offer autolinking as a feature in our ELF toolchain. We would >> like to see full support for this feature upstream as there is anecdotal >> evidence that

On Thu, Mar 14, 2019 at 9:28 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I guess I agree it would be best to remove the objfile linker option > support and replace it with just auto-linking. We already have a mechanism > for adding new features to object files: .note sections. Linkers already > know to ignore ones that they don't

Hi Nick, On 8/27/2013 12:45 AM, Nick Kledzik wrote: > On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: >> Can we add deadStrip() to undefinedAtoms as well ? >> >> This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. >> >> Also I think it will be cleaner for atoms to be added to deadStripRoot set using a

I am looking for pros and cons on the Intel Atom cpu. Has anybody been using these in production? I am looking at an Atom D510 (dual core 1.6GHz, 1M cache) to run maybe 25 to 30 extensions, 4 or 5 calls at once(maybe as high as 7 simultaneous calls), g729 all the way through except voicemail will be wav format for email purposes(requirement). I will be tying 3 of these together to route