0

i was using the console for resolving a "errno" like this:

-> strerror(0x23)
value = 22279888 = 0x153f6d0
-> d 0x153f6d0
NOTE: memory values are displayed in hexadecimal.
0x0153f6d0:  5f53 7265 6e72 5f6f 4e45 544f 5553 0050  *S_errno_ENOTSUP.*
0x0153f6e0:  0000 0000 0000 0000 0000 0000 0000 0000  *................*
...
0x0153f7c0:  0000 0000 0000 0000 0000 0000 0000 0000  *................*
value = 0 = 0x0

Also, if i create a new variable:

-> a=6
New symbol "a" added to kernel symbol table.
a = 0x45446f60: value = 6 = 0x6

Now it is stored and available. But now i am wondering where are those bytes saved? Does the console make a mem allocation in the background or has it already allocated some RAM for those purposes? Should i be concerned where this is going to be saved? I guess those data is stored until reboot and eating up mem as long as i am working with the console.

I took a look into "Kernel Shell User's Guide" but couln't find an answer. (VxWorks 7.0)

Albrecht
  • 45
  • 6
  • After reading the Guide again, i guess it is defined with "SHELL_STACK_SIZE". – Albrecht Feb 21 '19 at 12:35
  • I don't think it would be saved into the stack, as it is quite likely to overflow if shell is used for a long time. Shell stack should be used instead when the user makes a function call from the stack. I don't have access to any material right now, but I remember the kernel API having functions like "releaseShellStrings" and something similar for the variables. If memory is tight for you, I suggest you look into those functions. – Emut Feb 23 '19 at 07:02

1 Answers1

0

strerror returns pointer to error text by error number. Error text isn't some dynamic string, it's predefined constant known before compilation starts, so it must be stored in .data segment along with all other constants, next to all other initialized data. Whenever you call strerror with the same param, you get the same address of the same memory area, feel free to try.

Creating new variable is a different thing, it actually allocates memory from the heap the same way malloc/new does. If you call malloc for small amount of data (e.g. 16 bytes) right after creating new variable, you might get pointer really close to the address of new variable. And even more, you can call free &a from console to correctly release memory back, no error should appear.

You can actually study memory map if you want to

  • Start and size of stack/heap should be determined somewhere within your project configuration
  • You can ask linker to generate .map file like this and check segments addresses in it.

So either way you'll be able to guess memory section by pointer value

Note, I worked with older versions of VxWorks only (5.5 which has ), so this might not be inaccurate, but the main idea should be OK.

nnovich-OK
  • 2,900
  • 2
  • 13
  • 16