Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
2 edited body
source | link

On GNU/Linux, x86/x86-64, in general, what is the reason that (at least sometimes, maybe there are exceptions) 3264-bit library code cannot be used by a 6432-bit program?

I'm aware of many of the differences between x86-64 and x86, long-mode, the extended registers, the new registers, the removal (to some extent) of segments.

But why does this matter? The changes in long mode that are related to privileged code doesn't apply to system libraries, unless they run in kernel mode, which they don't.

As for the user land changes, larger registers, new registers, etc. why does this matter? On a 64-bit system the CPU would already be running in long-mode when it enters user space, and with long-mode being backwards compatible in this context (without even switching to protected mode), it should be able to use both 32-bit and 64-bit code, in user space.

Am I missing something obvious here?

Now, of course, if the 64-bit library simply has a different API, or that it is simply with a different name, e.g. running ldd might show that it is looking for a shared library with a different name than the 32-bit equivalent. That would be a problem. Although the solution (even if a kludge) would be very easy if that was all there is to it.

I can also imagine that since the x86-64 calling convention is different from regular x86, that would be a problem with even calling the functions in the library. Surely this must be part of the problem?

But it feels like there should be a better reason here, and I'm sure I'm missing something obvious.

On GNU/Linux, x86/x86-64, in general, what is the reason that (at least sometimes, maybe there are exceptions) 32-bit library code cannot be used by a 64-bit program?

I'm aware of many of the differences between x86-64 and x86, long-mode, the extended registers, the new registers, the removal (to some extent) of segments.

But why does this matter? The changes in long mode that are related to privileged code doesn't apply to system libraries, unless they run in kernel mode, which they don't.

As for the user land changes, larger registers, new registers, etc. why does this matter? On a 64-bit system the CPU would already be running in long-mode when it enters user space, and with long-mode being backwards compatible in this context (without even switching to protected mode), it should be able to use both 32-bit and 64-bit code, in user space.

Am I missing something obvious here?

Now, of course, if the 64-bit library simply has a different API, or that it is simply with a different name, e.g. running ldd might show that it is looking for a shared library with a different name than the 32-bit equivalent. That would be a problem. Although the solution (even if a kludge) would be very easy if that was all there is to it.

I can also imagine that since the x86-64 calling convention is different from regular x86, that would be a problem with even calling the functions in the library. Surely this must be part of the problem?

But it feels like there should be a better reason here, and I'm sure I'm missing something obvious.

On GNU/Linux, x86/x86-64, in general, what is the reason that (at least sometimes, maybe there are exceptions) 64-bit library code cannot be used by a 32-bit program?

I'm aware of many of the differences between x86-64 and x86, long-mode, the extended registers, the new registers, the removal (to some extent) of segments.

But why does this matter? The changes in long mode that are related to privileged code doesn't apply to system libraries, unless they run in kernel mode, which they don't.

As for the user land changes, larger registers, new registers, etc. why does this matter? On a 64-bit system the CPU would already be running in long-mode when it enters user space, and with long-mode being backwards compatible in this context (without even switching to protected mode), it should be able to use both 32-bit and 64-bit code, in user space.

Am I missing something obvious here?

Now, of course, if the 64-bit library simply has a different API, or that it is simply with a different name, e.g. running ldd might show that it is looking for a shared library with a different name than the 32-bit equivalent. That would be a problem. Although the solution (even if a kludge) would be very easy if that was all there is to it.

I can also imagine that since the x86-64 calling convention is different from regular x86, that would be a problem with even calling the functions in the library. Surely this must be part of the problem?

But it feels like there should be a better reason here, and I'm sure I'm missing something obvious.

1
source | link

Why cannot 64-bit shared libraries be used by 32-bit code?

On GNU/Linux, x86/x86-64, in general, what is the reason that (at least sometimes, maybe there are exceptions) 32-bit library code cannot be used by a 64-bit program?

I'm aware of many of the differences between x86-64 and x86, long-mode, the extended registers, the new registers, the removal (to some extent) of segments.

But why does this matter? The changes in long mode that are related to privileged code doesn't apply to system libraries, unless they run in kernel mode, which they don't.

As for the user land changes, larger registers, new registers, etc. why does this matter? On a 64-bit system the CPU would already be running in long-mode when it enters user space, and with long-mode being backwards compatible in this context (without even switching to protected mode), it should be able to use both 32-bit and 64-bit code, in user space.

Am I missing something obvious here?

Now, of course, if the 64-bit library simply has a different API, or that it is simply with a different name, e.g. running ldd might show that it is looking for a shared library with a different name than the 32-bit equivalent. That would be a problem. Although the solution (even if a kludge) would be very easy if that was all there is to it.

I can also imagine that since the x86-64 calling convention is different from regular x86, that would be a problem with even calling the functions in the library. Surely this must be part of the problem?

But it feels like there should be a better reason here, and I'm sure I'm missing something obvious.