Displaying 3 results from an estimated 3 matches for "utohexstr".
2020 Mar 30
2
LLD bug causing objcopy ELF to binary generation to create large binaries
...ype or flags are compatible with existing ones.
unsigned mask = SHF_TLS | SHF_LINK_ORDER;
if ((flags & mask) != (isec->flags & mask))
error("incompatible section flags for " + name + "\n>>> " + toString(isec) +
": 0x" + utohexstr(isec->flags) + "\n>>> output section " + name +
": 0x" + utohexstr(flags));
if (type != isec->type) {
if (!canMergeToProgbits(type) || !canMergeToProgbits(isec->type))
error("section type mismatch for " + isec->nam...
2020 Mar 29
2
LLD bug causing objcopy ELF to binary generation to create large binaries
Hi LLVM devs,
I came across an LLD bug in v 10.x where ELF parser / processor is
setting .PROGBITS attribute for .heap and .stack sections, which leads
to large binaries when we do `llvm-objcopy -o binary` to generate the
binary output for armv6m. (e.g. for a 57Kb elf would yield a ~400Mb
binary).
This in comparison with LLVM 7.x , would produce the correct binary size
of 35Kb and the
2007 Jul 15
3
[LLVMdev] Floating point constants (bug?)
>From the language guide:
"The one non-intuitive notation for constants is the optional
hexadecimal form of floating point constants. For example, the form
'double 0x432ff973cafa8000' is equivalent to (but harder to read than)
'double 4.5e+15'. The only time hexadecimal floating point constants
are required (and the only time that they are generated by the
disassembler) is