new port

new port

[Florent DEFAY]

Hi,

I work on porting GDB to a new arch.
I already ported GCC.

I meet some problems, I need help.

At the moment, I can use most of basic GDB commands.

I can set breakpoints and stop on them. I can set breakpoints on function names.
I can step. I can read locals and registers.

When I use the command 'next', it should step and skip functions. The
problem is that
indeed it steps but it does not skip functions. It step into the function.

Please help.


Regards.

Florent

Re: new port

[Hui Zhu]

I think maybe you code's frame analyze part have something wrong.

On Thu, May 14, 2009 at 21:23, Florent DEFAY <spira.inhabitant@gmail.com> wrote:
> Hi,
>
> I work on porting GDB to a new arch.
> I already ported GCC.
>
> I meet some problems, I need help.
>
> At the moment, I can use most of basic GDB commands.
>
> I can set breakpoints and stop on them. I can set breakpoints on function names.
> I can step. I can read locals and registers.
>
> When I use the command 'next', it should step and skip functions. The
> problem is that
> indeed it steps but it does not skip functions. It step into the function.
>
> Please help.
>
>
> Regards.
>
> Florent
>

RE: new port

[Anthony Berent]

Florent,

I have also been porting to a new architecture, and recently solved similar
problems with next. The way next works is that, after a step, it checks
whether an extra frame has been added to the stack. If it has, and various
other checks are satisfied, then it places a breakpoint on the return
address and runs on. Otherwise it simply stops after the first step.

Try stepping into the function using stepi, stopping at its first
instruction, and then having a look at the stack frames (using bt and "info
frames"). If these look wrong then that is probably your problem.

- Anthony

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
Of Florent DEFAY
Sent: 14 May 2009 14:24
To: gdb@sourceware.org
Subject: new port

Hi,

I work on porting GDB to a new arch.
I already ported GCC.

I meet some problems, I need help.

At the moment, I can use most of basic GDB commands.

I can set breakpoints and stop on them. I can set breakpoints on function
names.
I can step. I can read locals and registers.

When I use the command 'next', it should step and skip functions. The
problem is that
indeed it steps but it does not skip functions. It step into the function.

Please help.


Regards.

Florent

RE: new port

[Jeremy Bennett]

Hi Florent,

I had this problem with the OpenRISC port. It was caused by incorrect
prologue analysis, leading to the issues described by Hui Zhu and
Anthony Berent.

So I suggest looking at the skip_prologue function in your architectural
description. In my case, the problem was due to wrongly caching a value
rather than an address.

I wrote a HOWTO for porting GDB, based on my experience with the
OpenRISC. Some of that is now incorporated into the GNU Internals
manual, but you may find the original application note helpful:

        http://www.embecosm.com/download/ean3.html

HTH,


Jeremy

On Thu, 2009-05-14 at 15:05 +0100, Anthony Berent wrote:
> Florent,
> 
> I have also been porting to a new architecture, and recently solved similar
> problems with next. The way next works is that, after a step, it checks
> whether an extra frame has been added to the stack. If it has, and various
> other checks are satisfied, then it places a breakpoint on the return
> address and runs on. Otherwise it simply stops after the first step.
> 
> Try stepping into the function using stepi, stopping at its first
> instruction, and then having a look at the stack frames (using bt and "info
> frames"). If these look wrong then that is probably your problem.
> 
> - Anthony
> 
> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
> Of Florent DEFAY
> Sent: 14 May 2009 14:24
> To: gdb@sourceware.org
> Subject: new port
> 
> Hi,
> 
> I work on porting GDB to a new arch.
> I already ported GCC.
> 
> I meet some problems, I need help.
> 
> At the moment, I can use most of basic GDB commands.
> 
> I can set breakpoints and stop on them. I can set breakpoints on function
> names.
> I can step. I can read locals and registers.
> 
> When I use the command 'next', it should step and skip functions. The
> problem is that
> indeed it steps but it does not skip functions. It step into the function.
> 
> Please help.
> 
> 
> Regards.
> 
> Florent
> 
> 
-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: new port

[Florent DEFAY]

Thank you very much for the tips. You are right.

When I step into the function with stepi:
(1) If I try 'info frame' just before the first instruction, then
results an internal error.
(2) If I try 'info frame' just after the first intsuction, then I get
frame information.

I set up traces to know which functions GDB crosses in my target-tdep.c.
I can tell that skip_prologue is called only after processing the
first instruction,
I think it should be called before, shouldn't it?

Thank you for the HOWTO, I jump on it.

Regards.

Florent

2009/5/14 Anthony Berent <Anthony.Berent@arm.com>:
> Florent,
>
> I have also been porting to a new architecture, and recently solved similar
> problems with next. The way next works is that, after a step, it checks
> whether an extra frame has been added to the stack. If it has, and various
> other checks are satisfied, then it places a breakpoint on the return
> address and runs on. Otherwise it simply stops after the first step.
>
> Try stepping into the function using stepi, stopping at its first
> instruction, and then having a look at the stack frames (using bt and "info
> frames"). If these look wrong then that is probably your problem.
>
> - Anthony
>
> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
> Of Florent DEFAY
> Sent: 14 May 2009 14:24
> To: gdb@sourceware.org
> Subject: new port
>
> Hi,
>
> I work on porting GDB to a new arch.
> I already ported GCC.
>
> I meet some problems, I need help.
>
> At the moment, I can use most of basic GDB commands.
>
> I can set breakpoints and stop on them. I can set breakpoints on function
> names.
> I can step. I can read locals and registers.
>
> When I use the command 'next', it should step and skip functions. The
> problem is that
> indeed it steps but it does not skip functions. It step into the function.
>
> Please help.
>
>
> Regards.
>
> Florent
>
>
>

Re: new port

[Hui Zhu]

http://teawater.googlepages.com/epgdb1.txt
This doc is about porting gdb.  It told something about howto write
frame part.  It is old but maybe can help something.

http://sourceware.org/gdb/current/onlinedocs/gdbint_7.html#SEC45
Gdbint introduce something about frame too.

Thanks,
Hui

On Thu, May 14, 2009 at 22:46, Florent DEFAY <spira.inhabitant@gmail.com> wrote:
> Thank you very much for the tips. You are right.
>
> When I step into the function with stepi:
> (1) If I try 'info frame' just before the first instruction, then
> results an internal error.
> (2) If I try 'info frame' just after the first intsuction, then I get
> frame information.
>
> I set up traces to know which functions GDB crosses in my target-tdep.c.
> I can tell that skip_prologue is called only after processing the
> first instruction,
> I think it should be called before, shouldn't it?
>
> Thank you for the HOWTO, I jump on it.
>
> Regards.
>
> Florent
>
> 2009/5/14 Anthony Berent <Anthony.Berent@arm.com>:
>> Florent,
>>
>> I have also been porting to a new architecture, and recently solved similar
>> problems with next. The way next works is that, after a step, it checks
>> whether an extra frame has been added to the stack. If it has, and various
>> other checks are satisfied, then it places a breakpoint on the return
>> address and runs on. Otherwise it simply stops after the first step.
>>
>> Try stepping into the function using stepi, stopping at its first
>> instruction, and then having a look at the stack frames (using bt and "info
>> frames"). If these look wrong then that is probably your problem.
>>
>> - Anthony
>>
>> -----Original Message-----
>> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
>> Of Florent DEFAY
>> Sent: 14 May 2009 14:24
>> To: gdb@sourceware.org
>> Subject: new port
>>
>> Hi,
>>
>> I work on porting GDB to a new arch.
>> I already ported GCC.
>>
>> I meet some problems, I need help.
>>
>> At the moment, I can use most of basic GDB commands.
>>
>> I can set breakpoints and stop on them. I can set breakpoints on function
>> names.
>> I can step. I can read locals and registers.
>>
>> When I use the command 'next', it should step and skip functions. The
>> problem is that
>> indeed it steps but it does not skip functions. It step into the function.
>>
>> Please help.
>>
>>
>> Regards.
>>
>> Florent
>>
>>
>>
>

Re: new port

[Florent DEFAY]

Hi,

Jeremy,

I try to rewrite my target-tdep.c from the beginning taking
or1k-tdep.c as a template.

In the function or1k_frame_unwind_cache,
you get SP that way:
this_sp = or1k_unwind_sp (gdbarch, next_frame);

But this function could be called at any step of the prologue.
As SP is added the frame size at the beginning of the prologue,
I think this_sp is always the good value (the base). But in my case,
the prologue begins by pushing saved registers and then
SP changes at every step. So if I get SP by doing
this_sp = or1k_unwind_sp (gdbarch, next_frame);
I get the SP value at this step of the execution, not the final value.

(1) So I cannot find the base:
trad_frame_set_this_base (info, this_sp);
is not correct (the base is the final value, this_sp is not the final value).

(2) Plus, I need the SP when entering the called function because
this is where PREVIOUS PC is saved.

I think of a solution for (2):
As I know PC, I can compute how many saved regs pushes
have been already done. Then,
or1k_unwind_sp (gdbarch, next_frame) + NUM_PUSHES * REG_SIZE
gives me the SP when entering the function (falling stack).

Do you think this solution is ok?

Have you an idea for the issue (1) ?

Thank you.

Regards.

Florent

Re: new port

[Joel Brobecker]

> I think of a solution for (2):
> As I know PC, I can compute how many saved regs pushes
> have been already done. Then,
> or1k_unwind_sp (gdbarch, next_frame) + NUM_PUSHES * REG_SIZE
> gives me the SP when entering the function (falling stack).

That should correct, provided that your description of the frame
is correct. There's a somewhat similar situation with i386-tdep.c:
Normally, the frame pointer holds the frame address, but sometimes
functions are "frameless", and so we compute the frame base using
the stack pointer (your this_sp) and the frame size.  What's also
interesting with x86 is that, even when the frame uses a frame
pointer, the frame base address is actually an offset from what
that register contains (I think the offset is +8.  What I'm trying
to say is that, in the x86 case, the frame base is never the
content of a register, and that's not a necessity.

> (1) So I cannot find the base:
> trad_frame_set_this_base (info, this_sp);
> is not correct (the base is the final value, this_sp is not the final value).

This is related to your question above: You need to provide the value
of the frame base, which apparently is the value of the SP at the time
the function was entered.  It doesn't need to be the value of any given
register.

-- 
Joel

Re: new port

[Florent DEFAY]

> This is related to your question above: You need to provide the value
> of the frame base, which apparently is the value of the SP at the time
> the function was entered.  It doesn't need to be the value of any given
> register.

That's true. This problem about 'next' is solved.
Thank you Joel.

I still wonder:
What should return target_frame_base_address? The base of the frame?
Even when it is not a given register?

Now I am facing another problem which was not before.
If I debug a simple program: main calls foo, I got trouble with frames.
In foo, the result of 'info frame' is:
_______________________________________________
Stack level 0, frame at 0x3fca:
 pc = 0x40 in add15 (main.c:8); saved pc 0x32a
 Outermost frame: unwinder did not report frame ID
 source language c.
 Arglist at 0x3fc4, args: a=25
 Locals at 0x3fc4, Previous frame's sp is 0x3fca
 Saved registers:
  pc at 0x3fca
_______________________________________________

What is shocking me is "Outermost frame: unwinder did not report frame ID"
and "Previous frame's sp" which has the same value as "frame at".

I would like to know which functions could be involved in these problems?

Regards.

Florent

Re: new port

[Joel Brobecker]

> What should return target_frame_base_address? The base of the frame?
> Even when it is not a given register?

AFAIK, that's correct (again, look at the example of i386-tdep).

> Stack level 0, frame at 0x3fca:
>  pc = 0x40 in add15 (main.c:8); saved pc 0x32a
>  Outermost frame: unwinder did not report frame ID
>  source language c.
>  Arglist at 0x3fc4, args: a=25
>  Locals at 0x3fc4, Previous frame's sp is 0x3fca
>  Saved registers:
>   pc at 0x3fca
> _______________________________________________
> 
> What is shocking me is "Outermost frame: unwinder did not report frame ID"
> and "Previous frame's sp" which has the same value as "frame at".

I assume that frame 0 is for the call to "foo". What does "bt" say
in this situation?

-- 
Joel

Re: new port

[Florent DEFAY]

Thank you for reply.

>> What is shocking me is "Outermost frame: unwinder did not report frame ID"
>> and "Previous frame's sp" which has the same value as "frame at".
>
> I assume that frame 0 is for the call to "foo". What does "bt" say
> in this situation?

"Stack level 0" is returned whatever the function, whatever the real
stack level.
bt says
#0  main () at main.c:44
in main and
#0  foo (a=25) at main.c:6
in foo.

Regards.

Florent

Re: new port

[Florent DEFAY]

I finally resolved my problem. It was caused by "this_id" which was not set
as soon as the prologue begins but some instructions later.

Regards.

Florent

2009/5/25 Florent DEFAY <spira.inhabitant@gmail.com>:
> Thank you for reply.
>
>>> What is shocking me is "Outermost frame: unwinder did not report frame ID"
>>> and "Previous frame's sp" which has the same value as "frame at".
>>
>> I assume that frame 0 is for the call to "foo". What does "bt" say
>> in this situation?
>
> "Stack level 0" is returned whatever the function, whatever the real
> stack level.
> bt says
> #0  main () at main.c:44
> in main and
> #0  foo (a=25) at main.c:6
> in foo.
>
> Regards.
>
> Florent
>