I'm a newb with #GNU #binutils linker scripts, and am confused why

. = ALIGN((1<<LOG2CEIL(.-__logical_binary_start))/8);
.data : {

allows `.data` to be *before* the value that `.` gets set to; `ld --print-map` shows:

.rel.dyn 0x20007104 0x0
.rel.iplt 0x20007104 0x0 CMakeFiles/vpu_objs.dir/vpu.c.o
0x20008000 . = ALIGN (((0x1 << LOG2CEIL ((. - __logical_binary_start))) / 0x8))

.data 0x20007110 0x5dc
0x20007110 __data_start__ = .

I see how it gets 0x20007110 from 0x20007104--an input section in .data has alignment of 16. But I don't understand why it ignores the 0x20008000?

I can make it do what I want by doing

.data ALIGN((1<<LOG2CEIL(.-__logical_binary_start))/8) : {

but I'd like to understand why setting `.` doesn't do what I want.

#GCC #ARMv6M

Cursed knowledge unlocked:

--recursion-limit
--no-recursion-limit
Enables or disables a limit on the amount of recursion performed whilst demangling strings. Since the name mangling formats allow for an infinite level of recursion it is possible to create strings whose decoding will exhaust the amount of stack space available on the host machine, triggering a memory fault. The limit tries to prevent this from happening by restricting recursion to 2048 levels of nesting.

I'm not sure I want to even know how or in what circumstances demangling of symbol names can cause a literally infinite recursion ...

I wonder which demangler has this property. Looking at cplus_demangle_name_to_style from libiberty I see gnu-v3 (C++), java, gnat (Ada), dlang (D), and rust in there.

Thanks, #binutils aren't you ever a treasure trove? #sourceware #programming #cursedprogramming

One for fellow #ARM #Thumb and #gnu #binutils users...
Say I want to load the value "0x22000000" into R3.

Using "LDR R3, =0x22000000" drops the 32bit value in the literal pool, which encodes to 6 bytes.
A better encoding is: "MOVS R3, #0x88, LSLS R3, R3, #22" which saves 2 bytes.

Is there a pseudo-op or macro to generate the best possible encoding with GNU AS?

(I've been spoiled by RISC OS assemblers which kinda can, but now I'm writing code which others need to be able to assemble...)

GNU Binutils release 2.45.1 is now available

GNU Binutils release 2.45.1 is now available

Finally got around to install Linux/x86 binutils on my Apple Silicon Mac, so pwntools is happy to give me proper x86 shell code.

Remember, kids: not all the word is either Linux or x86

#ctf #cybersecurity #pwntools #binutils #mac #arm #x86

X86-64 playground

An online assembly editor, emulator, and debugger for the x86-64 architecture. Learn and experiment with assembly and system internals directly in your browser—no setup required

X86-64 playground

Today's `binutils-gdb` bug in `ld.bfd` is https://sourceware.org/PR33530.

There `ld.bfd` spends a ton of RAM and CPU time on inputs with huge section counts. In the example in initial comment `ld.gold` spends 50ms where `ld.bfd` spends 5s.

On real examples produced by haskell compiler with `-fsplit-section -optl-Wl,--gc-sections` it translates to extra minutes of link time on larger binaries.

I think it's an `ld` garbage collection bug.

#binutils #bug

33530 – ld --gc-sections is quadratic-slow on input with huge list of sections (20K)

One Open-source Project Daily

Simple makefile-based build for musl cross compiler

https://github.com/richfelker/musl-cross-make

#1ospd #opensource #binutils #crosscompiler #gcc #musl #muslcross #targetmusl #toolchain
GitHub - richfelker/musl-cross-make: Simple makefile-based build for musl cross compiler

Simple makefile-based build for musl cross compiler - richfelker/musl-cross-make

GitHub
Binutils - GNU Project - Free Software Foundation