How a function could crash the program which is not called

Hello, I just define a function but i have not called it yet...but it crashed...

There is no memory limit problem i have checked and there is not much local variables which might cause stack overflow.... any idea

--------------------------------------- Posted through

formatting link

Reply to
riggs
Loading thread data ...

You used a[i] = i++ on line 583 which caused the compiler to generate bad code.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

In the very, very unlikely case that the problem is not what Rich's suggests, it is possible that adding this function, (written in an unknown language, for an unknown platform, using unknown tools, with the wind blowing from an unknown direction,) changed the memory layout of your program so an existing memory corruption problem, which was harmless or at least undetected before, is now visible.

Please read

formatting link
formatting link

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

That's what I would have said. Probably even after knowing the pertinent details. It's not the world's commonest problem -- but that signature is pretty telling.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

the

My compiler is GCC and platform is ARM9 processor. I read linker script file and i found that layout is made according to code text size. But if i dont call a function why linker add assembly function to executable file. I tried to make the .text section of program larger, but no need to read linker script because linker script make layout acording to code size. So there is no way to add code to project. Now my solution is to eleminate some less needless codes from my project, because i have very small size of memory. Thanks for reading...

--------------------------------------- Posted through

formatting link

Reply to
riggs

[Since you are using gcc, I am assuming you are using binutils to do the linking.]

The comments about layout according to code size don't make any sense at all. You can split code by function (say, for example, a bootloader which needs to live in it's own unique hardware specific region) but that is not size related. Have you misunderstood what is going on here ?

The basic purpose of a linker script is for you to tell the linker what address regions it can write to, the size of those regions and which bits of your program you want in the various regions. The linker then takes your program and places it in those regions.

The only size directives should be the ones which describe the physical layout of your board's memory and these have no relationship to the actual size of your code. Could the real problem be that your code is simply too large for the board you are trying to run it on ?

If you have not done so already, have the linker generate a map listing and make sure that the various parts of your program are going where you expect and make sure that your program can physically fit in those regions.

If you are doing anything unusual with size directives, you need to state _exactly_ what you are doing.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

What Simon said: this comment doesn't seem to make much sense, unless you're using an automatically-generated linker script, which is not at all correct for embedded work.

Because you told it to -- you did write the function, after all. Traditionally the semantics for telling the linker "only add this code if I need it" is to put it in a library. Gnu has a method for doing this function-by-function in a code file but I can't remember all the details, and it's very "gnu-ish" (it uses an attribute, I _think_ that attribute is "weak", but I'm not at all sure -- RTFM).

If your linker is making your script, then you're doing something wrong for embedded work. You need to make the script (well, if you're a normal human you need to find a script that's close, and modify it for your processor).

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

Two things. On ARM targets I generally find you want to use the

-ffunction-sections and --gc-sections arguments. The first causes each function to be compiled into it's own section under .text, such as .text.my_func, etc. That improves the locality of your functions, which is useful in that it keeps your constant pools closer to the executable code, which allows for efficient addressing. But also, because it's in its own section, the second option (strip unused sections) will take it out of your executable.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

"Weak" is the one that lets you put default catch-all interrupt handlers into one module (declared as weak), and have the handlers in the real code replace them in the vector.

Mel.

Reply to
Mel Wilson

'weak' means that the linker does not complain if the symbol is already defined elsewhere - it simply ignores the piece of code, if it comes from a library file. 'weak' is intended to provide defaults for symbols that may be present or absent.

The linker is able to take or leave input file sections, so the process for unneeded code or data is two-step:

  1. Make the compiler to translate each function into a separate section with the --ffunction-sections switch. For module-wide data the corresponding switch is --fdata-sections.
  2. Make the linker to drop unused sections with the --gc-sections switch.

It is not always a good idea to drop data sections, as it may complicate the addressing of module-wide data.

--

Tauno Voipio
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.