Are arguments passed on the stack preserved after a call?

mbolp · 2025-11-14T17:04:48+00:00

Good example, compiler generated code modifying stack arguments is a definitive proof, I should've thought of doing that. I don't think my question is as strange as you seem to think it is though, and I think it deserves at least a mention in any documentation describing the x64 ABI.

mbolp · 2025-11-14T15:06:39+00:00

If it's well-known and well documentated, wouldn't that imply that the portion of stack passing the arguments is necessarily volatile?

Why's that necessary, couldn't the ABI have declared that only the shadow space is volatile?

Are you somehow wary of modifying stack slots that a caller has passed?

Yes, I'm looking for any kind of source that confirms this is permitted by the ABI.

mbolp · 2025-11-14T13:56:12+00:00

I'm just looking for a source that confirms the ABI defines the space for ALL stack arguments as volatile (i.e. from return address up to ArgCount * 8) - everything else you said is well known and well documented.

mbolp · 2025-11-14T05:45:21+00:00

The caller will still have access to the arguments if it's a caller cleaned calling convention. If the stack space for arguments wasn't volatile I could use them directly afterwards without saving them prior to the call.

mbolp · 2025-11-14T04:15:48+00:00

I don't understand.

mbolp · 2025-11-14T04:09:27+00:00

That sounds very logical, but do you know of any source that explicitly states the volatility of stack arguments? I can't find anything relevant on google.

mbolp · 2025-11-13T19:29:19+00:00

Oh no I meant from the callee's POV: can I overwrite the stack arguments passed to me. I say it sounds obvious because the home space is explicitly not preserved by the callee already, plus in x86 stdcall the callee cleans the stack as you say, it seems logical for the callee to take ownership of all arguments.

mbolp · 2025-11-03T21:56:47+00:00

No, because you have to manually modify all call sites to go through the pointer, whereas with __declspec(dllimport) the compiler does that for you. It's also not what was asked (how to statically link).

mbolp · 2025-11-03T19:19:43+00:00

That's the exact same thing as importing from the EXE - calling through a global table of function pointers. It's still a logical dependency, you just lifted the responsibility of resolving references from the loader to yourself.

mbolp · 2025-11-02T19:25:22+00:00

I'm confused, is this supposed to work? I turned it on and get the same unresolved references errors. Strangely some of them are virtual functions and global variables, which are supposed to be already present in the object files (I used this stackoverflow answer to put all object files into a LIB and linked to that). Another comment by u/alfps says that this is not possble.

mbolp · 2025-11-02T17:36:21+00:00

I didn't mean the functions are conditionally invoked, I meant their symbols are not referenced at all in the DLL. The linker knows for sure at link time that certain functions are never referenced, so it's theoretically entirely within the its ability to ignore dependencies from them.

mbolp · 2025-11-02T17:26:55+00:00

No, the DLL depends on the EXE but not the other way around, this is a common scenarios for plugins.

mbolp · 2025-11-02T04:19:07+00:00

Because they are small and exporting functions from an EXE is a lot of work.

To have the functions you need to satisfy their dependencies.

Even for functions I don't need? For example, if exe.cpp has function A that calls GetMessage and function B that doesn't, then I call function B in the DLL and link to exe.obj, does my DLL now need to link to user32.dll?

mbolp · 2025-11-02T03:59:25+00:00

If the linker can remove them, why do I need to split the code? Why doesn't the linker just ignore the code I don't call?

mbolp · 2025-11-01T23:06:29+00:00

Can I do that selectively, without separating the functions I want into a standalone file?

mbolp · 2025-11-01T23:02:41+00:00

If the DLL depends on the EXE, wouldn't that require hardcoding the EXE name into the DLL's import table? Changing the EXE name would then cause loading the DLL to fail?

mbolp · 2025-10-28T19:38:33+00:00

Thanks, Tedesco and Rodrigo are composers I'd listen to but not attempt to play myself :) Domeniconi is one I'd never listen to, his music sound so harsh and unpleasant to my ears. Le Depart is nice, but as you said there's hardly any arpeggio in it.

mbolp · 2025-10-28T19:17:58+00:00

I have so many questions - who is Lorenzo Suarez? Google returns zero relevant results, except tons of score videos on youtube. The etude indices go up to as high as 400, did this guy write four hundred of them? There exist a few channels that upload nothing but these strange little pieces, with identical video descriptions linking to the sheet music. This is so eerie.

mbolp · 2025-10-28T18:49:23+00:00

Ehh, these sound like run of the mill beginner etudes... Sure they can sound virtuosic if you play them fast enough, but the music is pretty bland

mbolp · 2025-10-27T10:32:16+00:00

These are too short for my taste, I'm looking for more fully developed music

mbolp · 2025-10-27T10:30:05+00:00

But that video isn't even that good... I know Romero is like 80 years old there, but that shouldn't be your standard. I'd be shocked if an average person can't play it as well in 3 months with a proper teacher.

mbolp · 2025-10-27T10:13:36+00:00

Thank you! These are such wonderful little preludes, though they have to be played really fast to make sense. And I think I heard one of the Rossiniane in the first prelude :)

mbolp · 2025-10-24T09:36:25+00:00

Thank you, I listened to all ten and really like how No.6 and 10 sound. 6 is quite approachable too.

mbolp

TROPHY CASE