Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.localhost!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: Return of the Overlays! Date: Wed, 14 Jan 2026 21:00:06 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10k904m$4h$1@reader2.panix.com> References: <10k6mhf$3hfn8$1@dont-email.me> <10k8uuq$2ep0$1@gal.iecc.com> Injection-Date: Wed, 14 Jan 2026 21:00:06 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="localhost:::1"; logging-data="145"; mail-complaints-to="abuse@panix.com" User-Agent: slrn/1.0.3 (Linux) Xref: csiph.com comp.arch.embedded:32455 On 2026-01-14, John Levine wrote: > According to Don Y : >>But, there is nothing in the traditional build process that >>ensures references from "some point" in the code don't refer >>back to some *other* point (that you thought you were done with). > > Depends on your tools. Indeed, it's pretty simple to do something like that with gcc and binutils. You can link each "chunk" separately so that it exposes only a few (or even no) global symbols. Then you link those chunks together to build an executable, you know there's a very limited (or empty) set of "connections" between them. However, that set of possible connections is static and doesn't change over time the way it does when you swap overlays in/out. I do this regularly to eliminate the possibilty of accidental name collisions and so that I know exactly what functions can by called by "others" outside a chunk/module. That's not quite the same as overlays, because all the chunks/modules are resident in memory all the time, and there might be multiple threads active in various different chunks at any point in time -- even though they can't access each other's functions or variables. -- Grant