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

Groups > comp.os.linux.embedded > #523 > unrolled thread

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

Back to article view | Back to comp.os.linux.embedded

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

On 08/02/2011 20:03, Lew Pitcher wrote:
> On February 8, 2011 13:16, in comp.os.linux.embedded, rajesha@domain-xyz.in
> wrote:
>
>> Hello,
>>
>>   Please can somebody let me know how to read power PC 8260 program counter
>> using C program (Using asm directive).
>
> That seems to me to be a "fools errand". By the time you've read the program
> counter, the program counter has changed. Each instruction executed changes
> the program counter, and in a multi-processing architecture like Linux,
> each context switch changes the program counter as well. By the time your
> code has retrieved the counter, the counter has changed.
>
> Anyway, it's a trivial thing to get the PC (or reasonable facsimile) in C
> code:
>
>   void dummy(void)
>   {
>     void (*pc)() =&dummy; /* got the PC on entry to the function */
>     /*
>     ...
>     */
>    }
>

I've had occasion to want to read the current PC from within a program. 
  I've used it as a simple way to distinguish between running from flash 
after startup, or running from ram via a debugger.  I'm sure there are 
other uses too, perhaps involving debugging or testing, or diagnostic 
outputs on error.

[toc] | [next] | [standalone]

#524

On Feb 9, 9:16 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Feb 9, 7:32 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
>
>
> > On 08/02/2011 20:03, Lew Pitcher wrote:
>
> > > On February 8, 2011 13:16, in comp.os.linux.embedded, raje...@domain-xyz.in
> > > wrote:
>
> > >> Hello,
>
> > >>   Please can somebody let me know how to read power PC 8260 program counter
> > >> using C program (Using asm directive).
>
> > > That seems to me to be a "fools errand". By the time you've read the program
> > > counter, the program counter has changed. Each instruction executed changes
> > > the program counter, and in a multi-processing architecture like Linux,
> > > each context switch changes the program counter as well. By the time your
> > > code has retrieved the counter, the counter has changed.
>
> > > Anyway, it's a trivial thing to get the PC (or reasonable facsimile) in C
> > > code:
>
> > >   void dummy(void)
> > >   {
> > >     void (*pc)() =&dummy; /* got the PC on entry to the function */
> > >     /*
> > >     ...
> > >     */
> > >    }
>
> > I've had occasion to want to read the current PC from within a program.
> >   I've used it as a simple way to distinguish between running from flash
> > after startup, or running from ram via a debugger.  I'm sure there are
> > other uses too, perhaps involving debugging or testing, or diagnostic
> > output s on error.
>
> I see. You really don't care about the program counter; you just want
> to know where your program was loaded.

FWIW, it would be better to just look at the contents of /proc/<pid>/
maps for the pid of the process in question. That'll show you exactly
where each loadable element of your process is placed in memory.

[toc] | [prev] | [next] | [standalone]

#529

On 09/02/2011 16:01, Lew Pitcher wrote:
> On Feb 9, 9:16 am, Lew Pitcher<lpitc...@teksavvy.com>  wrote:
>> On Feb 9, 7:32 am, David Brown<da...@westcontrol.removethisbit.com>
>> wrote:
>>
>>
>>
>>> On 08/02/2011 20:03, Lew Pitcher wrote:
>>
>>>> On February 8, 2011 13:16, in comp.os.linux.embedded, raje...@domain-xyz.in
>>>> wrote:
>>
>>>>> Hello,
>>
>>>>>    Please can somebody let me know how to read power PC 8260 program counter
>>>>> using C program (Using asm directive).
>>
>>>> That seems to me to be a "fools errand". By the time you've read the program
>>>> counter, the program counter has changed. Each instruction executed changes
>>>> the program counter, and in a multi-processing architecture like Linux,
>>>> each context switch changes the program counter as well. By the time your
>>>> code has retrieved the counter, the counter has changed.
>>
>>>> Anyway, it's a trivial thing to get the PC (or reasonable facsimile) in C
>>>> code:
>>
>>>>    void dummy(void)
>>>>    {
>>>>      void (*pc)() =&dummy; /* got the PC on entry to the function */
>>>>      /*
>>>>      ...
>>>>      */
>>>>     }
>>
>>> I've had occasion to want to read the current PC from within a program.
>>>    I've used it as a simple way to distinguish between running from flash
>>> after startup, or running from ram via a debugger.  I'm sure there are
>>> other uses too, perhaps involving debugging or testing, or diagnostic
>>> output s on error.
>>
>> I see. You really don't care about the program counter; you just want
>> to know where your program was loaded.
>
> FWIW, it would be better to just look at the contents of /proc/<pid>/
> maps for the pid of the process in question. That'll show you exactly
> where each loadable element of your process is placed in memory.
>

Ops, I hadn't noticed that this is comp.os.linux.embedded - I had 
assumed I was still in comp.arch.embedded.  My system was bare-bones. 
Sorry for any confusion.

[toc] | [prev] | [next] | [standalone]

#527

On Feb 9, 7:32 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 08/02/2011 20:03, Lew Pitcher wrote:
>
>
>
> > On February 8, 2011 13:16, in comp.os.linux.embedded, raje...@domain-xyz.in
> > wrote:
>
> >> Hello,
>
> >>   Please can somebody let me know how to read power PC 8260 program counter
> >> using C program (Using asm directive).
>
> > That seems to me to be a "fools errand". By the time you've read the program
> > counter, the program counter has changed. Each instruction executed changes
> > the program counter, and in a multi-processing architecture like Linux,
> > each context switch changes the program counter as well. By the time your
> > code has retrieved the counter, the counter has changed.
>
> > Anyway, it's a trivial thing to get the PC (or reasonable facsimile) in C
> > code:
>
> >   void dummy(void)
> >   {
> >     void (*pc)() =&dummy; /* got the PC on entry to the function */
> >     /*
> >     ...
> >     */
> >    }
>
> I've had occasion to want to read the current PC from within a program.
>   I've used it as a simple way to distinguish between running from flash
> after startup, or running from ram via a debugger.  I'm sure there are
> other uses too, perhaps involving debugging or testing, or diagnostic
> output s on error.

I see. You really don't care about the program counter; you just want
to know where your program was loaded.

So, the above code sample should be all you need for that. Just test
the value of <pc> to see if it fits within the range of addresses that
map to flash or the range of addresses that map to ram.

HTH
--
Lew Pitcher
Master Codewright and JOAT-in-training

[toc] | [prev] | [next] | [standalone]

#528

On 09/02/2011 15:16, Lew Pitcher wrote:
> On Feb 9, 7:32 am, David Brown<da...@westcontrol.removethisbit.com>
> wrote:
>> On 08/02/2011 20:03, Lew Pitcher wrote:
>>
>>
>>
>>> On February 8, 2011 13:16, in comp.os.linux.embedded, raje...@domain-xyz.in
>>> wrote:
>>
>>>> Hello,
>>
>>>>    Please can somebody let me know how to read power PC 8260 program counter
>>>> using C program (Using asm directive).
>>
>>> That seems to me to be a "fools errand". By the time you've read the program
>>> counter, the program counter has changed. Each instruction executed changes
>>> the program counter, and in a multi-processing architecture like Linux,
>>> each context switch changes the program counter as well. By the time your
>>> code has retrieved the counter, the counter has changed.
>>
>>> Anyway, it's a trivial thing to get the PC (or reasonable facsimile) in C
>>> code:
>>
>>>    void dummy(void)
>>>    {
>>>      void (*pc)() =&dummy; /* got the PC on entry to the function */
>>>      /*
>>>      ...
>>>      */
>>>     }
>>
>> I've had occasion to want to read the current PC from within a program.
>>    I've used it as a simple way to distinguish between running from flash
>> after startup, or running from ram via a debugger.  I'm sure there are
>> other uses too, perhaps involving debugging or testing, or diagnostic
>> output s on error.
>
> I see. You really don't care about the program counter; you just want
> to know where your program was loaded.
>
> So, the above code sample should be all you need for that. Just test
> the value of<pc>  to see if it fits within the range of addresses that
> map to flash or the range of addresses that map to ram.
>

I can't speak for the OP, but for my own use (which was not on a PPC, so 
I don't have direct code), I needed to know where the code was running 
from at the time.  However, your code would not have helped me - it 
returns the logical address that the linker uses for when the program is 
running.  But when starting up (without a debugger), my program only 
existed as a copy in flash - the real run-time copy of the program was 
linked to run from ram, and needed to be copied over.  So if I took the 
address of the "dummy" function, it would give the address in ram - I 
needed the real PC (or at least, I needed to determine the higher bits 
of the real PC).  It is not even safe to call a function directly at 
this stage - it would have to be done using a function pointer and some 
bit masking of the address.

So for my use, the processor's "LEA" instruction was the most convenient 
correct method.  Other possibilities include using a safe function call 
(either using a corrected function pointer, or a relatively address 
function call if the processor supports it) and gcc's 
"__builtin_return_address" function.

[toc] | [prev] | [next] | [standalone]

#530

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

[toc] | [prev] | [next] | [standalone]

#535

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.

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

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

-- 

Tauno Voipio
tauno voipio (at) iki fi

[toc] | [prev] | [next] | [standalone]

#537

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.embedded

csiph-web