Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.embedded > #530

Re: Reading power PC MPC 8260 program counter (Next Instruction address)

Show all headers | View raw

Tauno Voipio wrote:
> On 11.2.11 10:31 , Jeff Jonas wrote:
>> Perhaps I'm being rather naive about the situation
>> but unless you're trying to get the address after memory mapping
>> and/or virtual memory translation, won't
>>      &(main)
>> give the address of main(),
>> enough to determine if it's in RAM or ROM in an embedded system?
>>
>> Profiling system calls&  libraries such as profil(3)
>> give indirect access to the program counter.
>>
>> Try as I might, I don't see a way to access the program counter
>> even via a signal handler since the return address is on the stack-frame
>> which is not usually accessible (but can be via stack-variable tricks).
> 
> In C, the name of a function is a constant pointer to
> the function (without the address operator &):
> 
> int main()
>   {
>   ;
>   }
> 
> then
> 
>   main
> 
> is a pointer to an int function without specified arguments.

True.

> The expression &main and &(main) should get complaints from
> the compiler.

False. The '&' is redundant, but it is allowed. To my mind it is clearer 
to use it than to omit it, as one more indication that the intent is not 
to call the function but to take its address.

Quoting from the C99 standard:

    6.5.3.2 Address and indirection operators

    Constraints

    1 The operand of the unary & operator shall be either a
      function designator, the result of a [] or unary * operator,
      or an lvalue that designates an object that is not a
      bit-field and is not declared with the register
      storage-class specifier.

Note the case of "a function designator".

> The pointer is existing in the compiled code without any
> library or operating system support required.

For a statically linked program the address &foo is a link-time constant 
that shows where the linker placed foo, which is where the linker 
expects foo to lie at execution time. As other posts in this thread have 
explained, if the code is in fact loaded or copied to another address 
and is sufficiently position-independent, the actual address at 
execution time may be different. To get the real address, you must read 
the actual Program Counter in some way.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Back to comp.os.linux.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Reading power PC MPC 8260 program counter (Next Instruction address) David Brown <david@westcontrol.removethisbit.com> - 2011-02-09 13:32 +0100
  Re: Reading power PC MPC 8260 program counter (Next Instruction address) Lew Pitcher <lpitcher@teksavvy.com> - 2011-02-09 07:01 -0800
    Re: Reading power PC MPC 8260 program counter (Next Instruction address) David Brown <david@westcontrol.removethisbit.com> - 2011-02-09 16:44 +0100
  Re: Reading power PC MPC 8260 program counter (Next Instruction address) Lew Pitcher <lpitcher@teksavvy.com> - 2011-02-09 06:16 -0800
    Re: Reading power PC MPC 8260 program counter (Next Instruction address) David Brown <david@westcontrol.removethisbit.com> - 2011-02-09 16:42 +0100
      Re: Reading power PC MPC 8260 program counter (Next Instruction address) Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-02-12 09:35 +0100
      Re: Reading power PC MPC 8260 program counter (Next Instruction address) Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-02-12 10:06 +0200
      Re: Reading power PC MPC 8260 program counter (Next Instruction address) jeffj@panix.com (Jeff Jonas) - 2011-02-11 03:31 -0500

csiph-web