search for: stt_section

+llvmdev On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, in light of some > recent changes in the writer, may need another update. WriterELF is > looking for atoms of type, typeFirstInSection (STT_SECTION) but the > reader isn't classifying those yet. > > I know there has been some discussion about discarding symbols of type > STT_SECTION but I don't think that is safe. This section would never > make it into the final executable: > >> .section .monkey, "a",...

...ion Center, Inc is a member of the Code Aurora Forum On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, in light of some > recent changes in the writer, may need another update. WriterELF is > looking for atoms of type, typeFirstInSection (STT_SECTION) but the > reader isn't classifying those yet. > > I know there has been some discussion about discarding symbols of type > STT_SECTION but I don't think that is safe. This section would never > make it into the final executable: > >> .section .monkey, "a"...

...e object file. A file symbol has STB_LOCAL binding and its section index is SHN_ABS. This symbol, if present, precedes the other STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an STT_FILE symbol representing the file itself. Conventionally, this symbols is followed by the files STT_SECTION symbols, and any global symbols that have been reduced to locals. This sounds like these symbols are not really about absolute address (e.g. ROM), but a way to sneak meta data (like source file name) into the object file. > > What do the V1 suffixes mean in the Native code? I had to ad...

...also attached as a patch file): Index: include/llvm/Object/ELF.h =================================================================== --- include/llvm/Object/ELF.h (revision 172846) +++ include/llvm/Object/ELF.h (working copy) @@ -1000,7 +1000,7 @@ switch (symb->getType()) { case ELF::STT_SECTION: - Result = Section ? Section->sh_addr : UnknownAddressOrSize; + Result = Section ? Section->sh_offset : UnknownAddressOrSize; return object_error::success; case ELF::STT_FUNC: case ELF::STT_OBJECT: -Andy -------------- next part -------------- An HTML attachment was scrubbe...

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

...e object file. A file symbol has STB_LOCAL binding and its section index is SHN_ABS. This symbol, if present, precedes the other STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an STT_FILE symbol representing the file itself. Conventionally, this symbols is followed by the files STT_SECTION symbols, and any global symbols that have been reduced to locals. > > This sounds like these symbols are not really about absolute address (e.g. ROM), but a way to sneak meta data (like source file name) into the object file. > > > >> >> What do the V1 suffixes mean in th...

...e symbol has STB_LOCAL binding and > its section index is SHN_ABS. This symbol, if present, precedes the other > STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an > STT_FILE symbol representing the file itself. Conventionally, this symbols > is followed by the files STT_SECTION symbols, and any global symbols that > have been reduced to locals. > >> > >> This sounds like these symbols are not really about absolute address > (e.g. ROM), but a way to sneak meta data (like source file name) into the > object file. > >> > >> > &...

...e object file. A file symbol has STB_LOCAL binding and its section index is SHN_ABS. This symbol, if present, precedes the other STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an STT_FILE symbol representing the file itself. Conventionally, this symbols is followed by the files STT_SECTION symbols, and any global symbols that have been reduced to locals. >> >> This sounds like these symbols are not really about absolute address (e.g. ROM), but a way to sneak meta data (like source file name) into the object file. >> >> >> >>> >>> W...

...e object file. A file symbol has STB_LOCAL binding and its section index is SHN_ABS. This symbol, if present, precedes the other STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an STT_FILE symbol representing the file itself. Conventionally, this symbols is followed by the files STT_SECTION symbols, and any global symbols that have been reduced to locals. > >> > >> This sounds like these symbols are not really about absolute address (e.g. ROM), but a way to sneak meta data (like source file name) into the object file. > >> > >> > >> > &g...

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

...d of OS-specific */ +#define STB_LOPROC 13 /* start of processor-specific */ +#define STB_HIPROC 15 /* end of processor-specific */ + +#define STT_NOTYPE 0 /* symbol type is unspecified */ +#define STT_OBJECT 1 /* symbol is a data object */ +#define STT_FUNC 2 /* symbol is a code object */ +#define STT_SECTION 3 /* symbol associated with a section */ +#define STT_FILE 4 /* symbol's name is file name */ +#define STT_COMMON 5 /* symbol is a common data object */ +#define STT_TLS 6 /* symbol is thread-local data object*/ +#define STT_NUM 7 /* number of defined types. */ +#define STT_LOOS 10 /* start...

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

...uot;what to do about mixed single input" case directly (though >> might allow the user to dodge the decision at least). Yeah, --symbol-ordering-file applies on both global and local symbols. Unfortunately no symbols are defined relative to .debug_* sections (if we don't consider the STT_SECTION symbols, which cannot be used anyway because .debug_* do not have unique names). (The usage of -u still requires the user to add archives (they want to change order) before other object files. In LLD this requires https://reviews.llvm.org/D81052 ) >> > Other ideas I had involved changing...

...uot;what to do about mixed single input" case directly (though >> might allow the user to dodge the decision at least). Yeah, --symbol-ordering-file applies on both global and local symbols. Unfortunately no symbols are defined relative to .debug_* sections (if we don't consider the STT_SECTION symbols, which cannot be used anyway because .debug_* do not have unique names). (The usage of -u still requires the user to add archives (they want to change order) before other object files. In LLD this requires https://reviews.llvm.org/D81052 ) >> > Other ideas I had involved changin...

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 Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that