Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 24.04 LTS will enable frame pointers by default

ubuntu.com

Post reply on HN
Print view View original

51–60 of 121 posts

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#51

Post by globular-toast »

mFixman wrote: post #38
jcranmer wrote: post #26

Earlier quoted context omitted.

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

Could programs compiled in architectures with 16 general purpose registers fail in one with 15?

Well, for a start you probably mean compiled for an arch with 16 registers. It doesn't actually matter what arch the compiler ran on (assuming modern cross-compiler like GCC).

If a program uses 16 registers then it needs 16 registers. But note it's the program itself that decides to use a frame pointer, it's not being reserved by the operating system or something. Programs don't even have to use the stack pointer as a stack pointer, they could use all 16 as general purpose, but in practice almost all programs use a call stack (I guess all C programs must do, but you might be able to disable it if you make no function calls?)

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#52

Post by ghotli »

o11c wrote: post #36
ghotli wrote: post #30

I somewhat painstakingly figured this out the hard way pulling core dumps off of embedded linux devices that gdb had a hard time working with. At the time I was like whew why is omitting frame pointers the default at all in so many places when it didn't seem to make a measurable difference in the performance of the software. I guess it's just vestigial these days and yes please use a compiler flag like this when it m…

Something has to be seriously wrong with the way it was compiled for gdb to have trouble. Debugging (or in-process exception dumps), which only does a reasonable number of backtraces, should always be able to use separate unwind data sections. Including frame pointers should only have a performance effect for sample-based profiling, which does a very large number of backtraces. And the general fact is - people don't…

> Something has to be seriously wrong with the way it was compiled for gdb to have trouble.

Cargo culting culture in embedded devices of just using some old toolchain copy pasted from some vendor seems to be pervasive. I cut fresh compilers and align their output with the old crusty toolchains. Made entire classes of issues go away. Regardless, agreed the omission of the frame pointer was merely one issue at play with those particular core dumps on those particular devices, years back at this point. :)

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#53

Post by mFixman »

globular-toast wrote: post #51
mFixman wrote: post #38

Earlier quoted context omitted.

Could programs compiled in architectures with 16 general purpose registers fail in one with 15?

Well, for a start you probably mean compiled for an arch with 16 registers. It doesn't actually matter what arch the compiler ran on (assuming modern cross-compiler like GCC). If a program uses 16 registers then it needs 16 registers. But note it's the program itself that decides to use a frame pointer, it's not being reserved by the operating system or something. Programs don't even have to use the stack pointer as…

Ohh, I misunderstood what Ubuntu was doing.

So the only change is that GCC and its toolkit will compile programs using a register as frame pointer by default? That seems like a very reasonable change. If having an extra general purpose register is critical for performance of then this can be disabled in that program's the makefile.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#55

Post by uxp8u61q »

woodruffw wrote: post #28
solarkraft wrote: post #25

Earlier quoted context omitted.

Is that even practical nowadays? My understanding is that snap is deeply integrated. Don't some apt packages point to their snap variants?

It’s still possible, although increasingly annoying. I believe Firefox now points to its snap variant, which I discovered when it broke a bunch of my browser extensions. Switching to the official Mozilla PPA was easily enough, but left a bad taste; if Canonical continues down the route of silently nudging users onto snap, I’ll probably switch to Debian. (I have no particular opinions about snap itself, other than tha…

> if Canonical continues down the route of silently nudging users onto snap, I’ll probably switch to Debian.

Serious question: why don't you switch now? I guess I just don't see the point of ubuntu anymore.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#56

Post by woodruffw »

uxp8u61q wrote: post #55
woodruffw wrote: post #28

Earlier quoted context omitted.

It’s still possible, although increasingly annoying. I believe Firefox now points to its snap variant, which I discovered when it broke a bunch of my browser extensions. Switching to the official Mozilla PPA was easily enough, but left a bad taste; if Canonical continues down the route of silently nudging users onto snap, I’ll probably switch to Debian. (I have no particular opinions about snap itself, other than tha…

> if Canonical continues down the route of silently nudging users onto snap, I’ll probably switch to Debian. Serious question: why don't you switch now? I guess I just don't see the point of ubuntu anymore.

Laziness.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#57

Post by jcranmer »

mathiasgredal wrote: post #42
jcranmer wrote: post #26

Earlier quoted context omitted.

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

That's not really how registers or speculative execution works. Intuitively, you can think of assembly as trying to describe a graph of instruction dependencies. Having 16 registers in the ISA allows you to have 16 live outputs at any given "time". Speculative execution allows instructions to execute out-of-order, and to enable this, it has ~140 registers that allow it to have 140 live outputs at once, so that it can run some code while a really long load is waiting for its data.

From the ISA perspective, however, adding more registers means you have to spend more bits naming a register. With 16 registers, you need 12 bits of your instruction just to name the operands of a typical 3-address instruction (rA = rB op rC). With 128 registers, that is now a whopping 21 bits, which means code density is a more pressing issue.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#58

Post by mathiasgredal »

mdpye wrote: post #48
mathiasgredal wrote: post #42

Earlier quoted context omitted.

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

Because then it would need more registers for the other purpose? But actually the decision about which general purpose registers to use for what is made at compile time (hence we're discussion a compiler flag here, the frame pointer is not a hardware dictated feature), so the question is actually kind of moot. If the compiler is out of registers to allocate and instead uses the stack, the CPU isn't reasonably going t…

Sure, but wouldn’t it make sense to extend the instruction set to allow the compiler to use these registers instead of reserving them for speculative / out-of-order execution? It was just a thought i had after watching a talk by a compiler guy: https://youtu.be/2EWejmkKlxs?feature=shared&t=2409

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#59

Post by karmakaze »

brancz wrote: post #2

Frame pointers are such a destructive micro-optimization to omit by default, I am beyond excited about this collaboration with the folks at Canonical to make Ubuntu debuggable by default!

> Ubuntu leaps forward with frame pointers by default

Yeah it's more like "...will stop omitting frame pointers by default".

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#60

Post by peterfirefly »

mathiasgredal wrote: post #42
jcranmer wrote: post #26

Earlier quoted context omitted.

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

There is a difference between registers and register names.

he AMD64 architecture only has 15 general-purpose registers (because the stack pointer is mostly treated as if it were a GPR as well). It is customary to use one of those (bp/ebp/rbp depending on mode) as a base pointer register. That leaves 14 GPR register names.

The physical CPU the code runs on might have 200 physical registers -- those are the ones that matter for speculative, out-of-order execution -- but the code itself can only refer to 14 (or 15) GPRs at a time and has to include instructions to transfer values to/from memory or to/from XMM registers if that's not enough. Those extra instructions take up space + might slow the code down.

Post reply on HN