[TUHS] nm on Third Edition .o files?
dds at aueb.gr
Tue Dec 20 06:49:20 AEST 2016
Thank you so much for the explanation. I was aware that in old C
structures a->b references were interpreted as *(a + b), but didn't know
that early C was so close to B that it could run most B programs by just
adding some declarations. It seems a logical evolutionary and
What I'm trying to do is study the dependencies between the kernel's
files. Maybe a good approximation would be to consider all functions as
global and ignore variables.
On 19/12/2016 22:33, Steve Johnson wrote:
> That's a construction that's left over from B. The number on the left
> is a PDP-11 address, probably for some kind of control register.
> In B, all data was stored in the same sized bucket. For arrays, the
> bucket contained the address of the beginning of the storage allocated
> for the array. For data, the bucket contained the data. On a
> byte-addressed machine, Dennis had to do some real magic to load and
> execute these programs (e.g., shift addresses right by a bit). And, of
> course, because there were no types, there was no type checking, and
> thus no way to disambiguate structure members, so all names of structure
> members had to be unique. If one structure had a member "next", no
> other structure could have a member "next". (actually, it could if
> they were at the same offset in the two structures, but that was pretty
> dangerous...). And early C (originally called nb, "new B") had to be
> able to run most B programs by just adding some declarations...
> I can't help you with nm, but it might not tell you much if you had it...
> ----- Original Message -----
> "Diomidis Spinellis" <dds at aueb.gr>
> "TUHS main list" <tuhs at minnie.tuhs.org>
> Mon, 19 Dec 2016 21:47:28 +0200
> [TUHS] nm on Third Edition .o files?
> . . .
> However, I stumbled on the use of structure fields on things that
> structures, e.g. "0177776->int =| 300"
More information about the TUHS