C51, Linker, list of variables as pile up in memory

What do you mean by that?

uint8_t xdata globalMyVar[4];

for ( ii = 0; ii < 20; ii++ )
{
   globalMyVar[ii] = 0;
}

Note the instructions for post source code: www.danlhenry.com/.../keil_code.png

Thanks Andrew for your answer.
I understand that my post was not clear.
I'll rewrite

I wish the list of variables of my generated binary in the order as they will be located in memory when executed, indicating the memory address.

For the moment the only way I found to obtain this was
- taking the information from the file generated by the linker (.M51 test file)
- paste the symbol tables in an excel datasheet
- sort by memory value
- look for my variable and see what comes afterwards

Any decent linker is capable of given this list without all this manipulation.
May be this is because I could't find the correct linker switch ... (even after reading the manual several times)

Why I wish this list?

Because this information is very useful.

To stress the point that this information is useful I put a practical example. A binary code in production with a bug which overwrites memory places. To analyze the impact of such bug you must have the list of variables overwritten. This list is not just following the order of declaration of the variables, nor an alphabetic order, as you can check. You need to dig in the linker output.

About the beauty of the code, I was thinking was unimportant as it is not a discussion about c coding, my fault.

Regards
Daniel

I disagree.

When doing any analysis like this, I generally find that it is necessary for me to "massage" the linker's output into the form I require for my specific analysis at the time.

That's linkers in general - not just Keil's 8051 linkers.

I think you missed my point:

You said: "the memory pile-up is not as declared in the source code"

I replied: "What do you mean by that?"

ie, in what way(s) does the memory "pile-up" not match the source code?

You do realise that the 'C' programming language gives no guarantees as to how variables will be ordered in memory (apart from within a struct)?

ups, I didn't saw that the title was part of the reply.

Yes, I aware of no guarantees about the memory assignation/allocation by the C standards.

This is one reason more to have a nice text output by the linker with the variables in the order as they are located in memory. The linker already has this information in the last pass when writes the binary.

In my experience I'm able to get this list when using gcc (at least the architectures I use/used), renesas, texas, microchip and several other linkers I use/used.

(for the structs the order can depend if the compiler handles pack and or align optimization)

Round these parts engineer takes .MAP and stuffs it through an AWK script.
Or opens .MAP in an editor (TSE?) and selects columns and sorts.

So I wanted to look which were these overwritten variables.
just curious why?". what does it matter which were ovewritten

yes, in my case matters. Really I found the bug in an already deployed embedded application (about 1000 devices). That part of the code is used at the initialization and in some rare cases of partial setup. Several variables are "refreshed"/restored with the correct values later during execution, this is why it passed unnoticed.
To evaluate if it worth the cost and effort to reprogram all the devices I needed to evaluate how dangerous was the bug, to analyze this impact I needed to check which were the variables affected.

But anyway, apart from this case, normally I work with mission critical systems, redundant and under radiation so memory locations and its uses is highly important for me.

If you are still curious I can explain more details by regular mail.

Regards
Daniel

I work with mission critical systems

If it's mission critical, how the heck did a bug like that manage to get through in the first place?

It's situations like this that give software a bad name!

oh, how wondeefulit is to use plain numbers

uint8_t xdata globalMyVar[4];

for ( ii = 0; ii < 20; ii++ )
{ globalMyVar[ii] = 0;
}

using correct methodology would never have let this pass


#define SIZE_OF RALPH 4
uint8_t xdata globalMyVar[SIZE_OF RALPH];

for ( ii = 0; ii < SIZE_OF RALPH; ii++ )
{ globalMyVar[ii] = 0;
}

and, of course, crappy little variable names such as 'i' and 'ii' makes it even more error prone

To make a long explanation short, I wrote my first program 36 years ago (yes, 1982) and along all of these years I found myself bugs even in compilers, in the hardware (processors, coprocessors, logic, fpga, cplds, etc..) also after doing several reviews I'm never 100% sure there is something like bug free.
Your statement sounds strong for me, may be with time you'll learn that the only thing we can do is to reduce the risk the better we can but not to eliminate it ...

I think that there are other things that give software/firmware/hardware a bad name but this is to discuss with another cup of coffee...

Regards
Daniel

Thanks Pier, this is the only constructive focused answer up to know
Regards
Daniel

Sorry but I'm not in the mood to discuss about C coding today and is a bit off topic of what I asked in 1st place.

How to get a list of the variables sorted by address with C51 toolset.

Just let you know that the piece of code posted is not the real code and was a fast 4 line code to show a very simplified even understandable example.

Regards
Daniel

To make a long explanation short, I wrote my first program 36 years ago (yes, 1982) and along all of these years I found myself bugs even in compilers, in the hardware (processors, coprocessors, logic, fpga, cplds, etc..) also after doing several reviews I'm never 100% sure there is something like bug free.
Your statement sounds strong for me, may be with time you'll learn that the only thing we can do is to reduce the risk the better we can but not to eliminate it ...

I think that there are other things that give software/firmware/hardware a bad name but this is to discuss with another cup of coffee...

Regards
Daniel