similar to: [LLVMdev] LLD AbsoluteAtoms

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

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

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

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

On Aug 22, 2013, at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > I am planning to work on adding support for definining expressions for the Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The expression may be

On 8/22/2013 3:44 PM, Nick Kledzik wrote: > > Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. > Agreed. > > On one hand, this sounds

Hi Nick, We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. I want a way in the Reader to create specific atoms before the linker bootstraps. I didnt find a way to do that with the existing interfaces. The way it needs to work is as below :- 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) 2) ReaderELF reads each file and adds

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

On Fri, Mar 18, 2016 at 01:25:17PM -0700, Evgenii Stepanov via llvm-dev wrote: > Another option is to allow the conflict, and make the global always > override the section symbol. This is easy to do in the integrated > assembler, but it appears that GAS simply does not work this way. Don't we have a similar case for STT_FILE already? Joerg

Thanks for the reply Nick. I will use the Writer::addFiles functionality. Do you want to move the SimpleFile class to lld/Core ? It might be useful for other types of object files too(like for ELF here). How does typeFirstInSection/typeLastinSection know that the addresses that need to be used for those symbols are the symbol values for the section start / section end ? I didnt see

On Dec 7, 2012, at 11:51 AM, Shankar Easwaran wrote: > We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. > > I want a way in the Reader to create specific atoms before the linker bootstraps. > > I didnt find a way to do that with the existing interfaces. > > The way it needs to work is as below :- > > 1) ReaderELF creates

While working on some other changes I came across a problem where ELFObjectFile::getSymbolFileOffset was returning a different value than I expected in the case where the symbol in question was a section. Looking at the code, it seems obviously wrong, but I didn't want to just commit my change without at least asking if anyone knew of a good reason for the current behavior. I know there

Hi, currently LLVM does not handle the conflict between a section and a global _definition_ with the same name well. A section defines a local symbol with the same name (pointing to the start of the section). Depending on the order of declarations, LLVM either silently overrides the section symbol with the global, or crashes with fatal error: error in backend: symbol 'xxx' is already

On Aug 22, 2013, at 6:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 8/22/2013 3:44 PM, Nick Kledzik wrote: >> >> Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend

This is a patch that I've had kicking around that I never sent in. With it applied I can compile the module programs from module-init-tools: diff -uNr klibc-0.178/include/sys/elf32.h klibc-0.178-fogo/include/sys/elf32.h --- klibc-0.178/include/sys/elf32.h 2004-01-30 14:40:51.000000000 -0700 +++ klibc-0.178-fogo/include/sys/elf32.h 2004-09-20 09:15:58.000000000 -0600 @@ -7,6 +7,10 @@

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