• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1887 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

howto see what's in the data segment

Stijn Souffriau

C51 returns the following error:

*** ERROR C249: 'DATA': SEGMENT TOO LARGE

Rather than switching to the COMPACT or LARGE memory model I would like to manually declare some variables into xdata. I would however like to know what the compiler is actually putting in the data segment and what is taking up the most space. Is there some way I can get this information in the absence of the .MAP file?

Thanks,

Stijn

Parents
  • 0

    Is there some way I can get this information in the absence of the .MAP file?

    Somewhat obviously: no. The map file is precisely where you're supposed to get that information.

    One aspect in which compiler toolchains differ from each other is what their linkers do to their output files in case of a linking failure. Some will leave them alone (so you would still have the last workin version for reference), others will overwrite at least the (primary) map file with a new version documenting the failed attempt, usually including the error message(s) that cause the failure.

    Both behaviours make sense, and from a quick experiment, it appears BL51 exhibits the former, but LX51 the latter. Go figure ;-)

Reply
  • 0

    Is there some way I can get this information in the absence of the .MAP file?

    Somewhat obviously: no. The map file is precisely where you're supposed to get that information.

    One aspect in which compiler toolchains differ from each other is what their linkers do to their output files in case of a linking failure. Some will leave them alone (so you would still have the last workin version for reference), others will overwrite at least the (primary) map file with a new version documenting the failed attempt, usually including the error message(s) that cause the failure.

    Both behaviours make sense, and from a quick experiment, it appears BL51 exhibits the former, but LX51 the latter. Go figure ;-)

Children
  • 0 in reply to HansBernhard Broeker

    Make the DATA segment temporarily bigger - is that even possible (architecture defined) if so how?

    Depends what "too large" means in this context. If it's smaller than architecturally limited then make it bigger, if it's already at the limit then try redirecting 'data' into larger segments that can accommodate it. It was a general suggestion about how to look at the problem if the .MAP was the only way to consider how the compiler/linker were behaving.

    You're never going to get 2 gallons of crap in a 1 gallon bucket, so if it's architecturally defined to have less capacity than the source needs, someone writing the source needs to actually think about that when coding it.

    What's the floor plan for the code/data on the platform you took the code from?