search for: st_other

Hi, On MIPS st_other field in the ELF symbols table might contain some additional MIPS-specific flags besides visibility ones. These flags should be copied to the output linked file. If YAML => Native conversion is switched off, there is no problem. But in case of the conversion we lose st_other field values. So I...

...contentTypes set might solve the problem. Thanks for the idea. I try to implement it. On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > One way to do that is to add new visibility / contentTypes (whatever is > relevant) added for each of the values st_other picks ? > > What are the other values st_other can take on MIPS ? > > Shankar Easwaran > > > On 11/6/2014 8:50 AM, Simon Atanasyan wrote: >> >> Hi, >> >> On MIPS st_other field in the ELF symbols table might contain some >> additional MIPS-specific...

...mistic. It is possible to use the contentTypes field for > handling STO_MICROMIPS and I have a working solution but the solution > is really ugly. This approach has at least two the following > shortcomings: > > 1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the > st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16 > ...). Sometimes these flags can be even combined. If we use the > contentTypes field, we have to define a separate ContentType flag for > each such combination. So we get a combinatorics explosion. > > 2. If we handle MIPS s...

...the contentTypes field for > > handling STO_MICROMIPS and I have a working solution but the solution > > is really ugly. This approach has at least two the following > > shortcomings: > > > > 1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the > > st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16 > > ...). Sometimes these flags can be even combined. If we use the > > contentTypes field, we have to define a separate ContentType flag for > > each such combination. So we get a combinatorics explosion. > > > &gt...

...int>", that the linker can recognize when scanning the symbol table for an incoming object file. In an ELF symbol table entry: typedef struct { Elf32_Word st_name; Elf32_Addr st_value; Elf32_Word st_size; unsigned char st_info; unsigned char st_other; Elf32_Half st_shndx; } Elf32_Sym; typedef struct { Elf64_Word st_name; unsigned char st_info; unsigned char st_other; Elf64_Half st_shndx; Elf64_Addr st_value; Elf64_Xword st_size; } Elf64_Sym; The st_size and st_value fields...

...particular, if anyone were to use a tool which rewrites the symbol table, it'll break things, unless that tool knows about this special section. I wonder if it's possible to put the data in the symbol table. Unfortunately, there's not a whole lot of available space there... The "st_other" field has some space available -- only the bottom 2 bits are currently used in general for visibility, so one could imagine adding a flag at 0x04, perhaps, for this indicator. Unfortunately, the bits of this field are widely used by a variety of architecture-specific things, which makes that...

The section is .text, so I assume it’s got IMAGE_SCM_CNT_CODE set. The problem is the symbol is marked (read & execute), but the test is (read & !write), so the symbol gets marked as ST_Data instead of ST_Other. From: David Majnemer [mailto:david.majnemer at gmail.com] Sent: Friday, August 22, 2014 5:44 PM To: Ted Woodward Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType() COFF sections also contain stuff like IMAGE_SCN_CNT_CODE and IMAGE_SCN_C...

...nd -fsanitize=memtag. Protection of read-only globals would be enabled-by-default, but can be disabled at compile time behind a flag (likely -f(no)sanitize-memtag-ro-globals). a) Dynamic symbols (int f; extern int f;) 1. Mark all tagged global data symbols in the dynamic symbol table as st_other.STO_TAGGED. 2. Teach the loader to read the symbol table at load time (and dlopen()) prior to relocations, and apply random memory tags (via. `irg -> stg`) to each STO_TAGGED carrying global. b) Hidden Symbols (static int g; or -fvisibility=hidden) 1. Have the compiler mark...

...table for an incoming object file. In an ELF symbol table entry: > > > > typedef struct { > > Elf32_Word st_name; > > Elf32_Addr st_value; > > Elf32_Word st_size; > > unsigned char st_info; > > unsigned char st_other; > > Elf32_Half st_shndx; > > } Elf32_Sym; > > > > typedef struct { > > Elf64_Word st_name; > > unsigned char st_info; > > unsigned char st_other; > > Elf64_Half st_shndx; > > Elf64_Addr...

...le entry: > > > > typedef struct { > > Elf32_Word st_name; > > Elf32_Addr st_value; > > Elf32_Word st_size; > > unsigned char st_info; > > unsigned char st_other; > > Elf32_Half st_shndx; > > } Elf32_Sym; > > > > typedef struct { > > Elf64_Word st_name; > > unsigned char st_info; > > unsigned char st_other; > &gt...

...als would be enabled-by-default, but can be > disabled at compile time behind a flag (likely > -f(no)sanitize-memtag-ro-globals). > > > > > > a) Dynamic symbols (int f; extern int f;) > > > > Mark all tagged global data symbols in the dynamic symbol table as > st_other.STO_TAGGED. > > > > Teach the loader to read the symbol table at load time (and dlopen()) > prior to relocations, and apply random memory tags (via. `irg -> stg`) to > each STO_TAGGED carrying global. > > > > b) Hidden Symbols (static int g; or -fvisibility=hidden)...

...efault, but can be disabled at compile time behind a flag (likely -f(no)sanitize-memtag-ro-globals). >>> > >>> > >>> > a) Dynamic symbols (int f; extern int f;) >>> > >>> > Mark all tagged global data symbols in the dynamic symbol table as st_other.STO_TAGGED. >>> > >>> > Teach the loader to read the symbol table at load time (and dlopen()) prior to relocations, and apply random memory tags (via. `irg -> stg`) to each STO_TAGGED carrying global. >>> > >>> > b) Hidden Symbols (static int g; or...

...s can implement independently, not an > llvm vs compiler-rt internal design or android only design.) > > > > > a) Dynamic symbols (int f; extern int f;) > > > > 1. > > > > Mark all tagged global data symbols in the dynamic symbol table as > > st_other.STO_TAGGED. > > note: these bits are not really reserved for os or processor > specific use in ELF. in practice they are processor specific > so it will be STO_AARCH64_TAGGED. > > note2: undefined symbol references will need correct marking > too if objects may get copy relocat...

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan

...Elf32_Word st_name; > > > > > > Elf32_Addr st_value; > > > > > > Elf32_Word st_size; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf32_Half st_shndx; > > > > > > } Elf32_Sym; > > > > > > > > > > > > typedef struct { > > > > > > Elf64_Word st_name; > > &...

...Elf32_Word st_name; > > > > > > Elf32_Addr st_value; > > > > > > Elf32_Word st_size; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf32_Half st_shndx; > > > > > > } Elf32_Sym; > > > > > > > > > > > > typedef struct { > > > > > > Elf64_Word st_name; > > &...

I'm working on adding data detection to llvm-objdump, so it prints out raw data for symbols with type SymbolRef::ST_Data instead of disassembling them. This causes llvm/test/MC/ARM/Windows/mov32t-range.s to fail, because the symbol "truncation" comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to

...; > > Elf32_Addr st_value; >> > > > >> > > > Elf32_Word st_size; >> > > > >> > > > unsigned char st_info; >> > > > >> > > > unsigned char st_other; >> > > > >> > > > Elf32_Half st_shndx; >> > > > >> > > > } Elf32_Sym; >> > > > >> > > > >> > > > >> > > > typedef struct { >> &gt...

----- Original Message ----- > From: "Dimitry Andric" <dimitry at andric.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)" <llvmdev at cs.uiuc.edu>, "Tom Stellard" <tom at stellard.net> > Sent: Saturday, November 29, 2014 1:34:21 PM > Subject: Re: [LLVMdev]

...; > > > > > > Elf32_Addr st_value; > > > > > > > > Elf32_Word st_size; > > > > > > > > unsigned char st_info; > > > > > > > > unsigned char st_other; > > > > > > > > Elf32_Half st_shndx; > > > > > > > > } Elf32_Sym; > > > > > > > > > > > > > > > > typedef struct { > > > > > > > &...