Sign in

username or email:

password:



Not a member?
Forgot your Password?

Search Comp.Arch.Embedded



Search tips

Discussion Groups

See Also

DSPFPGA

Discussion Groups | Comp.Arch.Embedded | How a function could crash the program which is not called

There are 10 messages in this thread.

You are currently looking at messages 1 to 10.


So far in May, you have voted 0 times ou of a total of 20 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.

How a function could crash the program which is not called - riggs - 2012-08-30 10:25:00

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 http://www.EmbeddedRelated.com

Re: How a function could crash the program which is not called - Rich Webb - 2012-08-30 10:39:00

On Thu, 30 Aug 2012 09:25:47 -0500, "riggs" <26690@embeddedrelated>
wrote:

>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

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

-- 
Rich Webb     Norfolk, VA

Re: How a function could crash the program which is not called - Roberto Waltman - 2012-08-30 11:29:00

Rich Webb  wrote:
> "riggs" wrote:
>
>>Hello, I just define a function but i have not called it yet...but it
>>crashed...
>
>You used a[i] = i++ on line 583 which caused the compiler to generate
>bad code.

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
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.petri.co.il/how_to_ask_a_question.htm 
--
Roberto Waltman

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

Re: How a function could crash the program which is not called - Tim Wescott - 2012-08-30 12:59:00

On Thu, 30 Aug 2012 11:29:14 -0400, Roberto Waltman wrote:

> Rich Webb  wrote:
>> "riggs" wrote:
>>
>>>Hello, I just define a function but i have not called it yet...but it
>>>crashed...
>>
>>You used a[i] = i++ on line 583 which caused the compiler to generate
>>bad code.
> 
> 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
> http://www.catb.org/~esr/faqs/smart-questions.html
> http://www.petri.co.il/how_to_ask_a_question.htm

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Re: How a function could crash the program which is not called - riggs - 2012-08-31 01:05:00

>On Thu, 30 Aug 2012 11:29:14 -0400, Roberto Waltman wrote:
>
>> Rich Webb  wrote:
>>> "riggs" wrote:
>>>
>>>>Hello, I just define a function but i have not called it yet...but it
>>>>crashed...
>>>
>>>You used a[i] = i++ on line 583 which caused the compiler to generate
>>>bad code.
>> 
>> 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
>> http://www.catb.org/~esr/faqs/smart-questions.html
>> http://www.petri.co.il/how_to_ask_a_question.htm
>
>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.
>Why am I not happy that they have found common ground?
>
>Tim Wescott, Communications, Control, Circuits & Software
>http://www.wescottdesign.com
>

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 http://www.EmbeddedRelated.com

Re: How a function could crash the program which is not called - Simon Clubley - 2012-08-31 07:45:00

On 2012-08-31, riggs <26690@embeddedrelated> wrote:
>
> 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...	   
> 					

[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, c...@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: How a function could crash the program which is not called - Tim Wescott - 2012-08-31 13:54:00

On Fri, 31 Aug 2012 00:05:51 -0500, riggs wrote:

>>On Thu, 30 Aug 2012 11:29:14 -0400, Roberto Waltman wrote:
>>
>>> Rich Webb  wrote:
>>>> "riggs" wrote:
>>>>
>>>>>Hello, I just define a function but i have not called it yet...but it
>>>>>crashed...
>>>>
>>>>You used a[i] = i++ on line 583 which caused the compiler to generate
>>>>bad code.
>>> 
>>> 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
>>> http://www.catb.org/~esr/faqs/smart-questions.html
>>> http://www.petri.co.il/how_to_ask_a_question.htm
>>
>>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. Why am I not happy that they have
>>found common ground?
>>
>>Tim Wescott, Communications, Control, Circuits & Software
>>http://www.wescottdesign.com
>>
>>
> 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.

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.

> But if
> i dont call a function why linker add assembly function to executable
> file.

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).

> 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...

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Re: How a function could crash the program which is not called - Rob Gaddi - 2012-08-31 14:03:00

On Fri, 31 Aug 2012 00:05:51 -0500
"riggs" <26690@embeddedrelated> wrote:

> 
> 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 http://www.EmbeddedRelated.com

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.

Re: How a function could crash the program which is not called - Mel Wilson - 2012-08-31 14:12:00

Tim Wescott wrote:

> 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).

"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.


Re: How a function could crash the program which is not called - Tauno Voipio - 2012-08-31 14:31:00

On 31.8.12 8:54 , Tim Wescott wrote:
>>>
>>> Tim Wescott, Communications, Control, Circuits & Software
>>> http://www.wescottdesign.com
>
> 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).
>

'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