Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

Show all memory occupied by the program


Can you all please suggest a program which tell us the range of memry
addresses occupied by the given c program?

Ravi <ra.ravi.@gmail.com> writes:
> Can you all please suggest a program which tell us the range of memry
> addresses occupied by the given c program?

It can't be done in portable standard C.  Try asking in a newsgroup
that deals with your operating system.

--
Keith Thompson (The_Other_Keith) k@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <1180855032.631821.327@j4g2000prf.googlegroups.com>,

Ravi  <ra.ravi.@gmail.com> wrote:
>Can you all please suggest a program which tell us the range of memry
>addresses occupied by the given c program?

gmemusage

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=m...

It is SGI IRIX specific, but you just asked for *a* program, without
indicating anything about the operating systems that are useful
for your purposes.

There is absolutely no way to get information about memory address
ranges through pure C, and it seems highly unlikely that such
a facility would ever be added to C; for one thing, it's kinda
difficult to define what the address ranges should mean for embedded
systems. Information about memory address ranges is inherently system
specific, so you will need to continue your investigations in a
newsgroup that deals with your operating system.

--
   "No one has the right to destroy another person's belief by
   demanding empirical evidence."              -- Ann Landers

Ravi wrote:

> Can you all please suggest a program which tell us the range of
> memry addresses occupied by the given c program?

No.  Off-topic.

--
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi
<ra.ravi.@gmail.com> writes
>Can you all please suggest a program which tell us the range of memry
>addresses occupied by the given c program?

Try looking at the map file that is output by the compiler.

Ignore the netpolice.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson
<k@mib.org> writes

>Ravi <ra.ravi.@gmail.com> writes:
>> Can you all please suggest a program which tell us the range of memry
>> addresses occupied by the given c program?

>It can't be done in portable standard C.  Try asking in a newsgroup
>that deals with your operating system.

It has nothing to do with the OS it sounds like he is looking for the
map file that the compiler will output.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <qsnQXYBls7YGF@phaedsys.demon.co.uk>,
Chris Hills  <c@phaedsys.demon.co.uk> wrote:

>In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi
><ra.ravi.@gmail.com> writes
>>Can you all please suggest a program which tell us the range of memry
>>addresses occupied by the given c program?
>Try looking at the map file that is output by the compiler.

*What* map file output by the compiler? The compilers I use
(brand name compilers) don't output a map file; the toolsets
include tools to -generate- various forms of memory summaries,
but the compilers don't output memory maps.

Even the advice to look at map files is system specific.
--
  All is vanity.                                       -- Ecclesiastes

Chris Hills wrote:
> In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson
> <k@mib.org> writes
>> Ravi <ra.ravi.@gmail.com> writes:
>>> Can you all please suggest a program which tell us the range of memry
>>> addresses occupied by the given c program?

>> It can't be done in portable standard C.  Try asking in a newsgroup
>> that deals with your operating system.

> It has nothing to do with the OS it sounds like he is looking for the
> map file that the compiler will output.

That is, of course, absurd.  The output of the compiler tells you
*nothing* about the memory addresses used by the program.

Chris Hills wrote:
> In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi
> <ra.ravi.@gmail.com> writes
>> Can you all please suggest a program which tell us the range of memry
>> addresses occupied by the given c program?

> Try looking at the map file that is output by the compiler.

That is, of course, absurd.  The output of the compiler tells you
*nothing* about the memory addresses used by the program.

> Ignore the netpolice.

More important is to ignore Chris Hills, who obviously knows nothing.
In article <jswSn5B5t7YGF@phaedsys.demon.co.uk>,
Chris Hills  <c@phaedsys.demon.co.uk> wrote:

>In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson
><k@mib.org> writes
>>Ravi <ra.ravi.@gmail.com> writes:
>>> Can you all please suggest a program which tell us the range of memry
>>> addresses occupied by the given c program?
>>It can't be done in portable standard C.  Try asking in a newsgroup
>>that deals with your operating system.
>It has nothing to do with the OS it sounds like he is looking for the
>map file that the compiler will output.

Chris, I was really convinced that you knew better than that.

The OP's question is completely meaningless on some operating systems,
and on some other operating systems none of the major compilers generate
memory maps (though other tools might be able to generate them.)

The question is also not specific enough to be answerable by the
"memory map" pancea. If for a particular program, some of the
variables are tossed into a section marked as Demand Zero Paging,
an other variables are tossed into a section for Block Initialize Data,
and some of the code is put down below the 64K boundary so short addresses
can be used, and if there are unusued gaps between each of these, then
does the OP need to know the start and end of each and every used segment?
If there happen to be 5 unused bytes between the code for one function
and the code for another, is that detail required to be revealed, since
those 5 bytes are -not- part of the range of memory addresses
occupied by that program? Does the OP need to know where each DLL
or DSO will get mapped into in virtual address space? If the OP is
using a malloc that uses mmap() to bring pages into the virtual address
range then the mmap() could "fill in" any space not nailed down, in
which case the "range of memory addressed occupied by the given c program"
could only be determined by -running- the program.
--
   "No one has the right to destroy another person's belief by
   demanding empirical evidence."              -- Ann Landers

Chris Hills <c@phaedsys.org> writes:
> In article <1180855032.631821.327@j4g2000prf.googlegroups.com>,
> Ravi <ra.ravi.@gmail.com> writes
>>Can you all please suggest a program which tell us the range of memry
>>addresses occupied by the given c program?

> Try looking at the map file that is output by the compiler.

> Ignore the netpolice.

On the contrary, the so-called "netpolice" are trying to direct you to
a forum where you can actually get answers to your question.

--
Keith Thompson (The_Other_Keith) k@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <f40gtd$9h@canopus.cc.umanitoba.ca>, Walter Roberson
<rober@ibd.nrc-cnrc.gc.ca> writes

>In article <qsnQXYBls7YGF@phaedsys.demon.co.uk>,
>Chris Hills  <c@phaedsys.demon.co.uk> wrote:
>>In article <1180855032.631821.327@j4g2000prf.googlegroups.com>, Ravi
>><ra.ravi.@gmail.com> writes
>>>Can you all please suggest a program which tell us the range of memry
>>>addresses occupied by the given c program?

>>Try looking at the map file that is output by the compiler.

>*What* map file output by the compiler? The compilers I use
>(brand name compilers) don't output a map file; the toolsets
>include tools to -generate- various forms of memory summaries,
>but the compilers don't output memory maps.

All of the 30 odd I have do generate memory maps.

>Even the advice to look at map files is system specific.

Not at all. Memory maps are generated on a very wide range of compilers
for many targets.  Each memory map will be specific to the program in
question.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <f40i4t$bc@canopus.cc.umanitoba.ca>, Walter Roberson
<rober@ibd.nrc-cnrc.gc.ca> writes

As you say the OP's question is wide open. I think that all bar one of
my 30 odd compilers generate memory maps.

>The question is also not specific enough to be answerable by the
>"memory map" pancea.

True. It should prompt him to look at the memory map if he has one and
learn a bit. Otherwise he will have to be a lot more specific

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <5chv8nF317d8@mid.individual.net>, Martin Ambuhl
<mamb@earthlink.net> writes

>Chris Hills wrote:
>> In article <lnhcppxydd.@nuthaus.mib.org>, Keith Thompson  <kst-
>>u@mib.org> writes
>>> Ravi <ra.ravi.@gmail.com> writes:
>>>> Can you all please suggest a program which tell us the range of memry
>>>> addresses occupied by the given c program?

>>> It can't be done in portable standard C.  Try asking in a newsgroup
>>> that deals with your operating system.

>>  It has nothing to do with the OS it sounds like he is looking for the
>>map file that the compiler will output.

>That is, of course, absurd.  The output of the compiler tells you *nothing*
>about the memory addresses used by the program.

So would you care to explain the mythical output below?
It seems to have memory addresses for the program and the data. All the
compilers I use will do this.
(Compilers to mean compiler-linker combination of course unless you are
going to split hares)

LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 1

LX51 LINKER/LOCATER V4.09, INVOKED BY:
C:\KEIL\C51\BIN\LX51.EXE MAIN.obj, XBANKING.obj TO LARGE_RAM IXREF
CLASSES (HDATA (X:0X020000-X:0X02FFFF))

CPU MODE:     8051 MODE
MEMORY MODEL: SMALL

INPUT MODULES INCLUDED:
  MAIN.obj (MAIN)
         COMMENT TYPE 0: C51 V8.05a
  XBANKING.obj (?C?XBANKING)
         COMMENT TYPE 0: AX51 V3.01a
  C:\KEIL\C51\LIB\C51BS.LIB (?C_STARTUP)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CLDPTR)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CSTPTR)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (PRINTF)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?PLDIIDATA)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CCASE)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (PUTCHAR)
         COMMENT TYPE 1: A51 / ASM51 Assembler

ACTIVE MEMORY CLASSES OF MODULE:  LARGE_RAM (MAIN)

BASE        START       END         USED      MEMORY CLASS
==========================================================
X:000000H   X:020000H   X:02FFFFH   00C000H   HDATA
C:000000H   C:000000H   C:00FFFFH   000600H   CODE
I:000000H   I:000000H   I:00007FH   00001EH   DATA
X:000000H   X:000000H   X:00FFFFH   000001H   XDATA
I:000000H   I:000000H   I:0000FFH   000001H   IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT

MEMORY MAP OF MODULE:  LARGE_RAM (MAIN)

START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS SEGMENT NAME
=========================================================================

* * * * * * * * * * *   D A T A   M E M O R Y   * * * * * * * * * * * *
*
000000H   000007H   000008H   ---    AT..     DATA           "REG BANK
0"
000008H   00001DH   000016H   BYTE   UNIT     DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 ---    ---      **GAP**
000020H.0 000021H.0 000001H.1 BIT    UNIT     BIT _BIT_GROUP_
000021H.1 000021H   000000H.7 ---    ---      **GAP**
000022H   000022H   000001H   BYTE   UNIT     IDATA          ?STACK

* * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * *
*
000000H   000002H   000003H   ---    OFFS..   CODE ?CO??C_STARTUP?0
000003H   00000AH   000008H   ---    ---      **GAP**
00000BH   00000DH   000003H   BYTE   OFFS..   CODE ?MAIN?0000B
00000EH   00038EH   000381H   BYTE   UNIT     CODE ?PR?PRINTF?PRINTF
00038FH   000500H   000172H   BYTE   UNIT     CODE ?C?LIB_CODE
000501H   00059EH   00009EH   BYTE   UNIT     CODE ?PR?MAIN?MAIN
00059FH   0005C5H   000027H   BYTE   UNIT     CODE ?PR?PUTCHAR?PUTCHAR
0005C6H   0005E1H   00001CH   BYTE   UNIT     CODE ?CO?MAIN
0005E2H   0005FBH   00001AH   BYTE   UNIT     CODE ?PR?TIMER0?MAIN
0005FCH   000607H   00000CH   BYTE   UNIT     CODE ?C_C51STARTUP
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 2

* * * * * * * * * * *  X D A T A   M E M O R Y  * * * * * * * * * * * *
*
000000H   000000H   000001H   BYTE   UNIT     XDATA          ?XD?MAIN
000001H   01FFFFH   01FFFFH   ---    ---      **GAP**
020000H   02BFFFH   00C000H   BYTE   INSEG    HDATA ?FD?MAIN

OVERLAY MAP OF MODULE:   LARGE_RAM (MAIN)

FUNCTION/MODULE              BIT_GROUP   DATA_GROUP
--> CALLED FUNCTION/MODULE  START  STOP  START  STOP
====================================================
TIMER0/MAIN                 ----- -----  ----- -----

*** NEW ROOT **************

?C_C51STARTUP               ----- -----  ----- -----
  +--> ?PR?MAIN?MAIN

MAIN/MAIN                   ----- -----  0008H 0009H
  +--> ?CO?MAIN
  +--> ?PR?PRINTF?PRINTF

?CO?MAIN                    ----- -----  ----- -----

PRINTF/PRINTF               20H.0 21H.0  000AH 001DH
  +--> ?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR             ----- -----  ----- -----

PUBLIC SYMBOLS OF MODULE:  LARGE_RAM (MAIN)

      VALUE       CLASS    TYPE      PUBLIC SYMBOL NAME
      =================================================
      0000000AH   DATA     ---       ?_PRINTF517?BYTE
      0000000AH   DATA     ---       ?_PRINTF?BYTE
      0000000AH   DATA     ---       ?_SPRINTF517?BYTE
      0000000AH   DATA     ---       ?_SPRINTF?BYTE
      010004DBH   CODE     ---       ?C?CCASE
      01000496H   CODE     ---       ?C?CLDPTR
      0100038FH   CODE     NEAR LAB  ?C?CLDXPTR
      00000000H   NUMBER   ---       ?C?CODESEG
      010004B4H   CODE     ---       ?C?CSTPTR
      010003AAH   CODE     NEAR LAB  ?C?CSTXPTR
      010003BFH   CODE     NEAR LAB  ?C?ILDXPTR
      010003E3H   CODE     NEAR LAB  ?C?ISTXPTR
      01000445H   CODE     NEAR LAB  ?C?LLDXPTR
      01000477H   CODE     NEAR LAB  ?C?LSTXPTR
      010004CBH   CODE     ---       ?C?PLDIIDATA
      010003FCH   CODE     NEAR LAB  ?C?PLDXPTR
      01000427H   CODE     NEAR LAB  ?C?PSTXPTR
      00000000H   NUMBER   ---       ?C?XDATASEG
      00000000H   NUMBER   ---       ?C?XPAGE1RST
      00000084H   DATA     BYTE      ?C?XPAGE1SFR
      01000501H   CODE     ---       ?C_START
      01000000H   CODE     ---       ?C_STARTUP
      01000070H   CODE     ---       _PRINTF
      01000070H   CODE     ---       _PRINTF517
      0100059FH   CODE     ---       _PUTCHAR
      0100006AH   CODE     ---       _SPRINTF
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 3

      0100006AH   CODE     ---       _SPRINTF517
*SFR* 000000D0H.6 DATA     BIT       AC
*SFR* 000000E0H   DATA     BYTE      ACC
*SFR* 000000EFH   DATA     BYTE      ADCCON1
*SFR* 000000D8H   DATA     BYTE      ADCCON2
*SFR* 000000F5H   DATA     BYTE      ADCCON3
*SFR* 000000DAH   DATA     BYTE      ADCDATAH
*SFR* 000000D9H   DATA     BYTE      ADCDATAL
*SFR* 000000F4H   DATA     BYTE      ADCGAINH
*SFR* 000000F3H   DATA     BYTE      ADCGAINL
*SFR* 000000D8H.7 DATA     BIT       ADCI
*SFR* 000000F2H   DATA     BYTE      ADCOFSH
*SFR* 000000F1H   DATA     BYTE      ADCOFSL
*SFR* 000000F0H   DATA     BYTE      B
*SFR* 000000C8H   DATA     BIT       CAP2
*SFR* 000000D8H.5 DATA     BIT       CCONV
*SFR* 000000C8H.1 DATA     BIT       CNT2
*SFR* 000000F8H.2 DATA     BIT       CPHA
*SFR* 000000F8H.3 DATA     BIT       CPOL
*SFR* 000000D8H   DATA     BIT       CS0
*SFR* 000000D8H.1 DATA     BIT       CS1
*SFR* 000000D8H.2 DATA     BIT       CS2
*SFR* 000000D8H.3 DATA     BIT       CS3
*SFR* 000000D0H.7 DATA     BIT       CY
*SFR* 000000E8H.5 DATA     BIT       D0
*SFR* 000000E8H.3 DATA     BIT       D0EN
*SFR* 000000E8H.7 DATA     BIT       D1
*SFR* 000000E8H.6 DATA     BIT       D1EN
*SFR* 000000FAH   DATA     BYTE      DAC0H
*SFR* 000000F9H   DATA     BYTE      DAC0L
*SFR* 000000FCH   DATA     BYTE      DAC1H
*SFR* 000000FBH   DATA     BYTE      DAC1L
*SFR* 000000FDH   DATA     BYTE      DACCON
*SFR* 000000E8H   DATA     BYTE      DCON
*SFR* 000000D8H.6 DATA     BIT       DMA
*SFR* 000000D3H   DATA     BYTE      DMAH
*SFR* 000000D2H   DATA     BYTE      DMAL
*SFR* 000000D4H   DATA     BYTE      DMAP
*SFR* 00000083H   DATA     BYTE      DPH
*SFR* 00000082H   DATA     BYTE      DPL
*SFR* 00000084H   DATA     BYTE      DPP
*SFR* 000000A8H.7 DATA     BIT       EA
*SFR* 000000A8H.6 DATA     BIT       EADC
*SFR* 000000C6H   DATA     BYTE      EADRL
*SFR* 000000B9H   DATA     BYTE      ECON
*SFR* 000000BCH   DATA     BYTE      EDATA1
*SFR* 000000BDH   DATA     BYTE      EDATA2
*SFR* 000000BEH   DATA     BYTE      EDATA3
*SFR* 000000BFH   DATA     BYTE      EDATA4
*SFR* 000000A8H.4 DATA     BIT       ES
*SFR* 000000A8H.1 DATA     BIT       ET0
*SFR* 000000A8H.3 DATA     BIT       ET1
*SFR* 000000A8H.5 DATA     BIT       ET2
*SFR* 000000BAH   DATA     BYTE      ETIM1
*SFR* 000000BBH   DATA     BYTE      ETIM2
*SFR* 000000C4H   DATA     BYTE      ETIM3
*SFR* 000000A8H   DATA     BIT       EX0
*SFR* 000000A8H.2 DATA     BIT       EX1
*SFR* 000000C8H.3 DATA     BIT       EXEN2
*SFR* 000000C8H.6 DATA     BIT       EXF2
*SFR* 000000D0H.5 DATA     BIT       F0
*SFR* 000000D0H.1 DATA     BIT       F1
*SFR* 0000009BH   DATA     BYTE      I2CADD
*SFR* 000000E8H   DATA     BYTE      I2CCON
*SFR* 0000009AH   DATA     BYTE      I2CDAT
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 4

*SFR* 000000E8H   DATA     BIT       I2CI
*SFR* 000000E8H.3 DATA     BIT       I2CM
*SFR* 000000E8H.2 DATA     BIT       I2CRS
*SFR* 000000E8H.1 DATA     BIT       I2CTX
*SFR* 000000A8H   DATA     BYTE      IE
*SFR* 00000088H.1 DATA     BIT       IE0
*SFR* 00000088H.3 DATA     BIT       IE1
*SFR* 000000A9H   DATA     BYTE      IE2
*SFR* 000000B0H.2 DATA     BIT       INT0
*SFR* 000000B0H.3 DATA     BIT       INT1
*SFR* 000000B8H   DATA     BYTE      IP
*SFR* 000000F8H.7 DATA     BIT       ISPI
*SFR* 00000088H   DATA     BIT       IT0
*SFR* 00000088H.2 DATA     BIT       IT1
      02020000H   HDATA    ---       large_array
      01000501H   CODE     ---       main
*SFR* 000000E8H.5 DATA     BIT       MCO
*SFR* 000000E8H.6 DATA     BIT       MDE
*SFR* 000000E8H.4 DATA     BIT       MDI
*SFR* 000000E8H.7 DATA     BIT       MDO
*SFR* 000000D0H.2 DATA     BIT       OV
*SFR* 000000D0H   DATA    
...

read more »

In article <5chv9tF317d8@mid.individual.net>, Martin Ambuhl
<mamb@earthlink.net> writes

>Chris Hills wrote:
>> In article <1180855032.631821.327@j4g2000prf.googlegroups.com>,
>>Ravi  <ra.ravi.@gmail.com> writes
>>> Can you all please suggest a program which tell us the range of memry
>>> addresses occupied by the given c program?

>> Try looking at the map file that is output by the compiler.

>That is, of course, absurd.  The output of the compiler tells you
>*nothing* about the memory addresses used by the program.
>>  Ignore the netpolice.

>More important is to ignore Chris Hills, who obviously knows nothing.

:-)

Clearly one of use knows less than he thinks.

Before you ask.... this compiler aggressively overlays data so several
variables can have the same address.....

ACTIVE MEMORY CLASSES OF MODULE:  LARGE_RAM (MAIN)

BASE        START       END         USED      MEMORY CLASS
======================================================
X:000000H   X:020000H   X:02FFFFH   00C000H   HDATA
C:000000H   C:000000H   C:00FFFFH   000600H   CODE
I:000000H   I:000000H   I:00007FH   00001EH   DATA
X:000000H   X:000000H   X:00FFFFH   000001H   XDATA
I:000000H   I:000000H   I:0000FFH   000001H   IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT

MEMORY MAP OF MODULE:  LARGE_RAM (MAIN)

START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS SEGMENT NAME
======================================================
* * * * * * * * * * *   D A T A   M E M O R Y   * * * * * * * * * * * *
*
000000H   000007H   000008H   ---    AT..     DATA           "REG BANK
0"
000008H   00001DH   000016H   BYTE   UNIT     DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 ---    ---      **GAP**
000020H.0 000021H.0 000001H.1 BIT    UNIT     BIT _BIT_GROUP_
000021H.1 000021H   000000H.7 ---    ---      **GAP**
000022H   000022H   000001H   BYTE   UNIT     IDATA          ?STACK

* * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * *
*
000000H   000002H   000003H   ---    OFFS..   CODE ?CO??C_STARTUP?0
000003H   00000AH   000008H   ---    ---      **GAP**
00000BH   00000DH   000003H   BYTE   OFFS..   CODE ?MAIN?0000B
00000EH   00038EH   000381H   BYTE   UNIT     CODE ?PR?PRINTF?PRINTF
00038FH   000500H   000172H   BYTE   UNIT     CODE ?C?LIB_CODE
000501H   00059EH   00009EH   BYTE   UNIT     CODE ?PR?MAIN?MAIN
00059FH   0005C5H   000027H   BYTE   UNIT     CODE ?PR?PUTCHAR?PUTCHAR
0005C6H   0005E1H   00001CH   BYTE   UNIT     CODE ?CO?MAIN
0005E2H   0005FBH   00001AH   BYTE   UNIT     CODE ?PR?TIMER0?MAIN
0005FCH   000607H   00000CH   BYTE   UNIT     CODE ?C_C51STARTUP
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 2

* * * * * * * * * * *  X D A T A   M E M O R Y  * * * * * * * * * * * *
*
000000H   000000H   000001H   BYTE   UNIT     XDATA          ?XD?MAIN
000001H   01FFFFH   01FFFFH   ---    ---      **GAP**
020000H   02BFFFH   00C000H   BYTE   INSEG    HDATA ?FD?MAIN

OVERLAY MAP OF MODULE:   LARGE_RAM (MAIN)

FUNCTION/MODULE              BIT_GROUP   DATA_GROUP
--> CALLED FUNCTION/MODULE  START  STOP  START  STOP
====================================================
TIMER0/MAIN                 ----- -----  ----- -----

*** NEW ROOT **************

?C_C51STARTUP               ----- -----  ----- -----
   +--> ?PR?MAIN?MAIN

MAIN/MAIN                   ----- -----  0008H 0009H
   +--> ?CO?MAIN
   +--> ?PR?PRINTF?PRINTF

?CO?MAIN                    ----- -----  ----- -----

PRINTF/PRINTF               20H.0 21H.0  000AH 001DH
   +--> ?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR             ----- -----  ----- -----

PUBLIC SYMBOLS OF MODULE:  LARGE_RAM (MAIN)

       VALUE       CLASS    TYPE      PUBLIC SYMBOL NAME
       =================================================
       0000000AH   DATA     ---       ?_PRINTF517?BYTE
       0000000AH   DATA     ---       ?_PRINTF?BYTE
       0000000AH   DATA     ---       ?_SPRINTF517?BYTE
       0000000AH   DATA     ---       ?_SPRINTF?BYTE
       010004DBH   CODE     ---       ?C?CCASE
       01000496H   CODE     ---       ?C?CLDPTR
       0100038FH   CODE     NEAR LAB  ?C?CLDXPTR
       00000000H   NUMBER   ---       ?C?CODESEG
       010004B4H   CODE     ---       ?C?CSTPTR
       010003AAH   CODE     NEAR LAB  ?C?CSTXPTR
       010003BFH   CODE     NEAR LAB  ?C?ILDXPTR
       010003E3H   CODE     NEAR LAB  ?C?ISTXPTR
       01000445H   CODE     NEAR LAB  ?C?LLDXPTR
       01000477H   CODE     NEAR LAB  ?C?LSTXPTR
       010004CBH   CODE     ---       ?C?PLDIIDATA
       010003FCH   CODE     NEAR LAB  ?C?PLDXPTR
       01000427H   CODE     NEAR LAB  ?C?PSTXPTR
       00000000H   NUMBER   ---       ?C?XDATASEG
       00000000H   NUMBER   ---       ?C?XPAGE1RST
       00000084H   DATA     BYTE      ?C?XPAGE1SFR
       01000501H   CODE     ---       ?C_START
       01000000H   CODE     ---       ?C_STARTUP
       01000070H   CODE     ---       _PRINTF
       01000070H   CODE     ---       _PRINTF517
       0100059FH   CODE     ---       _PUTCHAR
       0100006AH   CODE     ---       _SPRINTF

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <5chv9tF317d8@mid.individual.net>, Martin Ambuhl
<mamb@earthlink.net> writes

>Chris Hills wrote:
>> In article <1180855032.631821.327@j4g2000prf.googlegroups.com
>>>, Ravi  <ra.ravi.@gmail.com> writes
>>> Can you all please suggest a program which tell us the range of memry
>>> addresses occupied by the given c program?

>> Try looking at the map file that is output by the compiler.

>That is, of course, absurd.  The output of the compiler tells you *nothing*
>about the memory addresses used by the program.
>>  Ignore the netpolice.

>More important is to ignore Chris Hills, who obviously knows nothing.

LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 1

LX51 LINKER/LOCATER V4.09, INVOKED BY:
C:\KEIL\C51\BIN\LX51.EXE MAIN.obj, XBANKING.obj TO LARGE_RAM IXREF
CLASSES (HDATA (X:0X020000-X:0X02FFFF))

CPU MODE:     8051 MODE
MEMORY MODEL: SMALL

INPUT MODULES INCLUDED:
  MAIN.obj (MAIN)
         COMMENT TYPE 0: C51 V8.05a
  XBANKING.obj (?C?XBANKING)
         COMMENT TYPE 0: AX51 V3.01a
  C:\KEIL\C51\LIB\C51BS.LIB (?C_STARTUP)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CLDPTR)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CSTPTR)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (PRINTF)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?PLDIIDATA)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (?C?CCASE)
         COMMENT TYPE 1: A51 / ASM51 Assembler
  C:\KEIL\C51\LIB\C51BS.LIB (PUTCHAR)
         COMMENT TYPE 1: A51 / ASM51 Assembler

ACTIVE MEMORY CLASSES OF MODULE:  LARGE_RAM (MAIN)

BASE        START       END         USED      MEMORY CLASS
==========================================================
X:000000H   X:020000H   X:02FFFFH   00C000H   HDATA
C:000000H   C:000000H   C:00FFFFH   000600H   CODE
I:000000H   I:000000H   I:00007FH   00001EH   DATA
X:000000H   X:000000H   X:00FFFFH   000001H   XDATA
I:000000H   I:000000H   I:0000FFH   000001H   IDATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT

MEMORY MAP OF MODULE:  LARGE_RAM (MAIN)

START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS SEGMENT NAME
=========================================================================

* * * * * * * * * * *   D A T A   M E M O R Y   * * * * * * * * * * * *
*
000000H   000007H   000008H   ---    AT..     DATA           "REG BANK
0"
000008H   00001DH   000016H   BYTE   UNIT     DATA _DATA_GROUP_
00001EH.0 00001FH.7 000002H.0 ---    ---      **GAP**
000020H.0 000021H.0 000001H.1 BIT    UNIT     BIT _BIT_GROUP_
000021H.1 000021H   000000H.7 ---    ---      **GAP**
000022H   000022H   000001H   BYTE   UNIT     IDATA          ?STACK

* * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * *
*
000000H   000002H   000003H   ---    OFFS..   CODE ?CO??C_STARTUP?0
000003H   00000AH   000008H   ---    ---      **GAP**
00000BH   00000DH   000003H   BYTE   OFFS..   CODE ?MAIN?0000B
00000EH   00038EH   000381H   BYTE   UNIT     CODE ?PR?PRINTF?PRINTF
00038FH   000500H   000172H   BYTE   UNIT     CODE ?C?LIB_CODE
000501H   00059EH   00009EH   BYTE   UNIT     CODE ?PR?MAIN?MAIN
00059FH   0005C5H   000027H   BYTE   UNIT     CODE ?PR?PUTCHAR?PUTCHAR
0005C6H   0005E1H   00001CH   BYTE   UNIT     CODE ?CO?MAIN
0005E2H   0005FBH   00001AH   BYTE   UNIT     CODE ?PR?TIMER0?MAIN
0005FCH   000607H   00000CH   BYTE   UNIT     CODE ?C_C51STARTUP
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 2

* * * * * * * * * * *  X D A T A   M E M O R Y  * * * * * * * * * * * *
*
000000H   000000H   000001H   BYTE   UNIT     XDATA          ?XD?MAIN
000001H   01FFFFH   01FFFFH   ---    ---      **GAP**
020000H   02BFFFH   00C000H   BYTE   INSEG    HDATA ?FD?MAIN

OVERLAY MAP OF MODULE:   LARGE_RAM (MAIN)

FUNCTION/MODULE              BIT_GROUP   DATA_GROUP
--> CALLED FUNCTION/MODULE  START  STOP  START  STOP
====================================================
TIMER0/MAIN                 ----- -----  ----- -----

*** NEW ROOT **************

?C_C51STARTUP               ----- -----  ----- -----
  +--> ?PR?MAIN?MAIN

MAIN/MAIN                   ----- -----  0008H 0009H
  +--> ?CO?MAIN
  +--> ?PR?PRINTF?PRINTF

?CO?MAIN                    ----- -----  ----- -----

PRINTF/PRINTF               20H.0 21H.0  000AH 001DH
  +--> ?PR?PUTCHAR?PUTCHAR

PUTCHAR/PUTCHAR             ----- -----  ----- -----

PUBLIC SYMBOLS OF MODULE:  LARGE_RAM (MAIN)

      VALUE       CLASS    TYPE      PUBLIC SYMBOL NAME
      =================================================
      0000000AH   DATA     ---       ?_PRINTF517?BYTE
      0000000AH   DATA     ---       ?_PRINTF?BYTE
      0000000AH   DATA     ---       ?_SPRINTF517?BYTE
      0000000AH   DATA     ---       ?_SPRINTF?BYTE
      010004DBH   CODE     ---       ?C?CCASE
      01000496H   CODE     ---       ?C?CLDPTR
      0100038FH   CODE     NEAR LAB  ?C?CLDXPTR
      00000000H   NUMBER   ---       ?C?CODESEG
      010004B4H   CODE     ---       ?C?CSTPTR
      010003AAH   CODE     NEAR LAB  ?C?CSTXPTR
      010003BFH   CODE     NEAR LAB  ?C?ILDXPTR
      010003E3H   CODE     NEAR LAB  ?C?ISTXPTR
      01000445H   CODE     NEAR LAB  ?C?LLDXPTR
      01000477H   CODE     NEAR LAB  ?C?LSTXPTR
      010004CBH   CODE     ---       ?C?PLDIIDATA
      010003FCH   CODE     NEAR LAB  ?C?PLDXPTR
      01000427H   CODE     NEAR LAB  ?C?PSTXPTR
      00000000H   NUMBER   ---       ?C?XDATASEG
      00000000H   NUMBER   ---       ?C?XPAGE1RST
      00000084H   DATA     BYTE      ?C?XPAGE1SFR
      01000501H   CODE     ---       ?C_START
      01000000H   CODE     ---       ?C_STARTUP
      01000070H   CODE     ---       _PRINTF
      01000070H   CODE     ---       _PRINTF517
      0100059FH   CODE     ---       _PUTCHAR
      0100006AH   CODE     ---       _SPRINTF
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 3

      0100006AH   CODE     ---       _SPRINTF517
*SFR* 000000D0H.6 DATA     BIT       AC
*SFR* 000000E0H   DATA     BYTE      ACC
*SFR* 000000EFH   DATA     BYTE      ADCCON1
*SFR* 000000D8H   DATA     BYTE      ADCCON2
*SFR* 000000F5H   DATA     BYTE      ADCCON3
*SFR* 000000DAH   DATA     BYTE      ADCDATAH
*SFR* 000000D9H   DATA     BYTE      ADCDATAL
*SFR* 000000F4H   DATA     BYTE      ADCGAINH
*SFR* 000000F3H   DATA     BYTE      ADCGAINL
*SFR* 000000D8H.7 DATA     BIT       ADCI
*SFR* 000000F2H   DATA     BYTE      ADCOFSH
*SFR* 000000F1H   DATA     BYTE      ADCOFSL
*SFR* 000000F0H   DATA     BYTE      B
*SFR* 000000C8H   DATA     BIT       CAP2
*SFR* 000000D8H.5 DATA     BIT       CCONV
*SFR* 000000C8H.1 DATA     BIT       CNT2
*SFR* 000000F8H.2 DATA     BIT       CPHA
*SFR* 000000F8H.3 DATA     BIT       CPOL
*SFR* 000000D8H   DATA     BIT       CS0
*SFR* 000000D8H.1 DATA     BIT       CS1
*SFR* 000000D8H.2 DATA     BIT       CS2
*SFR* 000000D8H.3 DATA     BIT       CS3
*SFR* 000000D0H.7 DATA     BIT       CY
*SFR* 000000E8H.5 DATA     BIT       D0
*SFR* 000000E8H.3 DATA     BIT       D0EN
*SFR* 000000E8H.7 DATA     BIT       D1
*SFR* 000000E8H.6 DATA     BIT       D1EN
*SFR* 000000FAH   DATA     BYTE      DAC0H
*SFR* 000000F9H   DATA     BYTE      DAC0L
*SFR* 000000FCH   DATA     BYTE      DAC1H
*SFR* 000000FBH   DATA     BYTE      DAC1L
*SFR* 000000FDH   DATA     BYTE      DACCON
*SFR* 000000E8H   DATA     BYTE      DCON
*SFR* 000000D8H.6 DATA     BIT       DMA
*SFR* 000000D3H   DATA     BYTE      DMAH
*SFR* 000000D2H   DATA     BYTE      DMAL
*SFR* 000000D4H   DATA     BYTE      DMAP
*SFR* 00000083H   DATA     BYTE      DPH
*SFR* 00000082H   DATA     BYTE      DPL
*SFR* 00000084H   DATA     BYTE      DPP
*SFR* 000000A8H.7 DATA     BIT       EA
*SFR* 000000A8H.6 DATA     BIT       EADC
*SFR* 000000C6H   DATA     BYTE      EADRL
*SFR* 000000B9H   DATA     BYTE      ECON
*SFR* 000000BCH   DATA     BYTE      EDATA1
*SFR* 000000BDH   DATA     BYTE      EDATA2
*SFR* 000000BEH   DATA     BYTE      EDATA3
*SFR* 000000BFH   DATA     BYTE      EDATA4
*SFR* 000000A8H.4 DATA     BIT       ES
*SFR* 000000A8H.1 DATA     BIT       ET0
*SFR* 000000A8H.3 DATA     BIT       ET1
*SFR* 000000A8H.5 DATA     BIT       ET2
*SFR* 000000BAH   DATA     BYTE      ETIM1
*SFR* 000000BBH   DATA     BYTE      ETIM2
*SFR* 000000C4H   DATA     BYTE      ETIM3
*SFR* 000000A8H   DATA     BIT       EX0
*SFR* 000000A8H.2 DATA     BIT       EX1
*SFR* 000000C8H.3 DATA     BIT       EXEN2
*SFR* 000000C8H.6 DATA     BIT       EXF2
*SFR* 000000D0H.5 DATA     BIT       F0
*SFR* 000000D0H.1 DATA     BIT       F1
*SFR* 0000009BH   DATA     BYTE      I2CADD
*SFR* 000000E8H   DATA     BYTE      I2CCON
*SFR* 0000009AH   DATA     BYTE      I2CDAT
 LX51 LINKER/LOCATER V4.09 06/04/2007  11:36:05  PAGE 4

*SFR* 000000E8H   DATA     BIT       I2CI
*SFR* 000000E8H.3 DATA     BIT       I2CM
*SFR* 000000E8H.2 DATA     BIT       I2CRS
*SFR* 000000E8H.1 DATA     BIT       I2CTX
*SFR* 000000A8H   DATA     BYTE      IE
*SFR* 00000088H.1 DATA     BIT       IE0
*SFR* 00000088H.3 DATA     BIT       IE1
*SFR* 000000A9H   DATA     BYTE      IE2
*SFR* 000000B0H.2 DATA     BIT       INT0
*SFR* 000000B0H.3 DATA     BIT       INT1
*SFR* 000000B8H   DATA     BYTE      IP
*SFR* 000000F8H.7 DATA     BIT       ISPI
*SFR* 00000088H   DATA     BIT       IT0
*SFR* 00000088H.2 DATA     BIT       IT1
      02020000H   HDATA    ---       large_array
      01000501H   CODE     ---       main
*SFR* 000000E8H.5 DATA     BIT       MCO
*SFR* 000000E8H.6 DATA     BIT       MDE
*SFR* 000000E8H.4 DATA     BIT       MDI
*SFR* 000000E8H.7 DATA     BIT       MDO
*SFR* 000000D0H.2 DATA     BIT       OV
*SFR* 000000D0H   DATA     BIT       P
*SFR* 00000080H   DATA     BYTE      P0
*SFR* 00000090H   DATA     BYTE      P1
*SFR* 000000A0H   DATA     BYTE      P2
*SFR* 000000B0H   DATA     BYTE      P3
*SFR* 000000B8H.6 DATA     BIT       PADC
*SFR* 00000087H   DATA     BYTE      PCON
*SFR* 000000C0H.5 DATA     BIT       PRE0
*SFR* 000000C0H.6 DATA     BIT       PRE1
*SFR*
...

read more »

On Mon, 4 Jun 2007 11:47:50 +0100, in comp.lang.c , Chris Hills

Still not certain to tell you where in memory different objects are.
The map will be a static picture of how stuff gets laid out, not a
dynamic picture of where it actuall is.

>>Even the advice to look at map files is system specific.

>Not at all.

Of course it is - by definition it has to be system specific...

>Memory maps are generated on a very wide range of compilers
>for many targets.  Each memory map will be specific to the program in
>question.

As you acknowledge here.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
 by definition, not smart enough to debug it."
--Brian Kernighan

On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills

<c@phaedsys.org> wrote:

>BASE        START       END         USED      MEMORY CLASS
>==========================================================
>X:000000H   X:020000H   X:02FFFFH   00C000H   HDATA

fascinating, but wildly offtopic, and highly specific to the
freestanding impementation you have to hand.

I also strongly suspect that this merely tells you where, relative to
some base, stuff might get laid out in a virtual map. Maps do not
generally tell you where it actually _is_ when you run the programme.

But you know that, this looks like hole-digging to me...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
 by definition, not smart enough to debug it."
--Brian Kernighan

In article <in28639gddeaovkrhqh1oqr2155cb2n@4ax.com>, Mark McIntyre
<markmcint@spamcop.net> writes

>On Mon, 4 Jun 2007 11:53:06 +0100, in comp.lang.c , Chris Hills
><c@phaedsys.org> wrote:

>>BASE        START       END         USED      MEMORY CLASS
>>==========================================================
>>X:000000H   X:020000H   X:02FFFFH   00C000H   HDATA

>fascinating, but wildly offtopic, and highly specific to the
>freestanding impementation you have to hand.

Yes This one is specific to the target in question   However I could
have generated a similar file from any of the 30 compilers I have.

However as the majority of compilers are for free-standing targets it is
not off topic.   BTW this compiler, as will most of the others I have
still generate an EXACT map file even when using an OS or RTOS or
scheduler.... So your premise is wrong anyway.

(Just see how many non x86 targets GCC has and therer are at least 5
other compiler vendors for any target compared to the number of current
PC compiler you can get.....   You are making an assumption as to the
target of the OP. Most PC/Linux programmers do this.

>I also strongly suspect that this merely tells you where, relative to
>some base, stuff might get laid out in a virtual map. Maps do not
>generally tell you where it actually _is_ when you run the programme.

You are COMPLETELY WRONG the map above give EXACT memory locations that
is the point of a Map file.  This is why I made the comment about the
data overlaying as some variables had the same address.

>But you know that, this looks like hole-digging to me...

You have dug your own hole The memory map given above give EXACT memory
locations. This is how you debug programs that are not dynamically
mapped which is, if not the majority a very sizeable minority.

You need to remember that for every x86 desktop system there are
probably 1000 embedded systems  on something like 60 different MCU types
from 8-128 bit systems.

Map files are used with Ice and Logic analysers to debug.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> [...] unless you are going to split hares

Do you have a score to settle with rabbits in general?

:-)

In article <46642e0c$0$29101$426a7@news.free.fr>, Spoon
<devn@localhost.com> writes

>Chris Hills wrote:

>> [...] unless you are going to split hares

>Do you have a score to settle with rabbits in general?

>:-)

Only if hungry.....
I used to have some ground with rabbits (also pheasant and partridge )
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> Ignore the netpolice.

Don't listen to this idiot. If you ignore the group consensus on
topicality, you'll quickly be marginalized. That means even when you
have a topical question, you'll not get answers because the majority
will be ignoring you.

You will get the best answers in the correct newsgroup.

Brian

On Mon, 4 Jun 2007 14:38:30 +0100, in comp.lang.c , Chris Hills

<c@phaedsys.org> wrote:
>In article <in28639gddeaovkrhqh1oqr2155cb2n@4ax.com>, Mark McIntyre
><markmcint@spamcop.net> writes

>>fascinating, but wildly offtopic, and highly specific to the
>>freestanding impementation you have to hand.

>Yes This one is specific to the target in question   However I could
>have generated a similar file from any of the 30 compilers I have.

>However as the majority of compilers are for free-standing targets it is
>not off topic.  

The majority of compilers emit textual error messages too. That
doesn't make specific text messages, or even the existence of text
mesages, topical. The standard is silent on how or indeed whether an
implementation must provide a textual error. It must merely emit one
diagnostic, which could equally be a beep, inverting video briefly, or
emitting a TCP packet.

>>I also strongly suspect that this merely tells you where, relative to
>>some base, stuff might get laid out in a virtual map. Maps do not
>>generally tell you where it actually _is_ when you run the programme.

>You are COMPLETELY WRONG the map above give EXACT memory locations

Why is precisely why wittering on about offtopic stuff here is
irresponsible. I can't call you on that, whether its true or not,
because I'm no expert in your platform.

>>But you know that, this looks like hole-digging to me...

>You have dug your own hole

Amusing.

>The memory map given above give EXACT memory
>locations.

On one very specific platform, using one very specific memory layout,
and with one very specific addressing strategy. It is completely
nonportable, probably totally unlike any other memory map and quite
off topic.

But as I said, you knew all this already...

>Map files are used with Ice and Logic analysers to debug.

No sh.. sherlock?

I disagree by the way, map files are used to provide my GPS with
cutesy pictures to show me where the nearest kebab shop is.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
 by definition, not smart enough to debug it."
--Brian Kernighan

He won't.  He gets his kicks form being rude, not admitting he is wrong.

--
Ian Collins.

In article <ueq8635oomui6uqov0mhc5nt2228msg@4ax.com>, Mark McIntyre
<markmcint@spamcop.net> writes

I was talking about the majority of platforms. It's not my problem that
you only have experience of a very few platforms or targets.

>>The memory map given above give EXACT memory
>>locations.

>On one very specific platform, using one very specific memory layout,
>and with one very specific addressing strategy. It is completely
>nonportable, probably totally unlike any other memory map and quite
>off topic.

As I said the file I showed was specific but is an example of the map
file the majority of compilers will do. The majority of compilers will
give exect memory locations.

 Wintel is one of the few exceptions. where it doesn't work.

I could give examples for another 30+ compilers including x86
targets.... all of which will give a similar file all with exact memory
locations that is the whole point of a map file.

>But as I said, you knew all this already...

I know your experience is so limited as to be pointless in this
discussion

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc