headers
Triple Yang | 1 Oct 2011 07:33
Picon

Re: command-list does not work in my gdb 7.2 port

I guess so.

Anyway, I find out what goes wrong in my port.

In <targ>-remote.c, we need to implement function
<target>_wait(struct target_ops *ops, ptid_t ptid, struct
target_waitstatus *status, int options), wherein STATUS is an output
parameter to store the target stop status. For a breakpoint hit, it
needs to be assigned with a trap signal, otherwise, COMMANDS won't
work.

Best regards.

2011/10/1 Liang Cheng <liang.cheng555 <at> gmail.com>:
> He probably means you can try the latest gdb release as he did not see
> such an issue.
>
> On Tue, Sep 27, 2011 at 2:06 AM, Triple Yang <triple.yang <at> gmail.com> wrote:
>> sorry, I do not understand what you are trying to say.
>>
>> 2011/9/27 Hui Zhu <teawater <at> gmail.com>:
>>> (gdb) b mainBreakpoint 1 at 0x40056c: file 1.c, line 3.(gdb) commands
>>> Type commands for breakpoint(s) 1, one per line.End with a line saying
>>> just "end".>shell echo 123>end(gdb) rStarting program:
>>> /home/teawater/gdb/a.out
>>> Breakpoint 1, main () at 1.c:33 {123
>>> Please try the trunk.
>>>
>>> Best,
>>> Hui
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 2 Oct 2011 04:04

Re: [PATCH] tcg: Use the GDB JIT debugging interface.

On Fri, Sep 30, 2011 at 10:36 AM, Richard Henderson <rth <at> twiddle.net> wrote:
> On 09/30/2011 12:12 AM, Jan Kiszka wrote:
>>> Breakpoint 1, __ldb_mmu (addr=1001716, mmu_idx=0)
>>>     at /home/rth/work/qemu/qemu/softmmu_template.h:86
>>> 86   {
>>> (gdb) where
>>> #0  __ldb_mmu (addr=1001716, mmu_idx=0)
>>>     at /home/rth/work/qemu/qemu/softmmu_template.h:86
>>> #1  0x0000000040000afc in ?? ()
> ...
>> Would it be possible to tag translated code as well? At TB or maybe even
>> input instruction level? Only in debugging mode of course.
>
> I don't know.  A couple of points on that:
>
> (1) I was rather expecting frame 1 above to be marked "code_gen_buffer"
>    rather than "??".  I *did* install that symbol in the generated
>    ELF image as a function covering the entire buffer.  So I'm not
>    quite sure why GDB didn't use it.

Totally wild guess: associated with the wrong section?  I don't
remember what we do w.r.t. ABS in shared libraries, but for non-ABS we
do validate what section we think things are in.  And I'm not sure if
we load section info in the JIT loader, either.

--

-- 
Thanks,
Daniel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joost van der Sluis | 2 Oct 2011 15:50
Picon
Favicon

Re: Handling of c++ function members

On Fri, 2011-09-30 at 10:42 -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 27, 2011 at 10:59 AM, Joost van der Sluis <joost <at> cnoc.nl> wrote:
> >> What I understood is, that DW_AT_vtable_elem_location should contain a
> >> Dwarf-block that calculates the location of a pointer in which the
> >> location of the function member is stored.
> 
> Your final conclusion is right - I thought the workaround was
> contained to the dwarf reader, but maybe not.

Indeed. The workaround in the dwarf-reader is when it encounters a
Dwarf-block for a DW_AT_vtable_elem_location entry, it assumes that the
dwarf-block contains a simple DW_OP_deref, a constant and DW_OP_plus.
Then it takes the constant, divides it by the pointer-size and then it
has the index-element, just like it had when using stabs or with older c
++ compilers.

So the actual Dwarf-block is not evaluated at all. But hey, it works
now, even with FPC. 

> Are you actually passing through gnu-v2-abi.c?  Everythong ought to be
> on the v3 abi unless this is another FPC quirk...

It's (as almost always) the other way around and a gcc quirk. The
default is gnu-v2. But when a symbol's name start with '_Z' then it is
set to gnu-v3.

Really, gdb contains a pile of hacks to get it working with gcc. That's
not a problem but sometimes difficult when other compilers try to work
with the official Dwarf-specifications.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joost van der Sluis | 3 Oct 2011 11:39
Picon
Favicon

Crash of Archer's gdb on mingw (passing null argument to vasprintf)

Hi all,

Maybe a strange question because it's not about stock gdb but about the
fedora16-branch from the Archer project. But I know that there are not
that much mingw/Windows people on the Archer mailinglist, so I ask here.

In gdbtypes.c there's this code:

    warning (_("Range for type %s has invalid bounds %s..%s"),
            TYPE_NAME (type), plongest (TYPE_LOW_BOUND (range_type)),
            plongest (TYPE_HIGH_BOUND (range_type)));

This goes wrong when TYPE_NAME (type) is null. Eventually warning()
leads to a call of vasprintf(), and on Fedora it prints '(NULL)' when it
encounters a null-parameter. But on mingw it crashes (sigint).

How to fix this properly? I could add a check for the assignment of
TYPE_NAME (type). Or should mingw fix their vasprintf implementation? Or
can I switch to another version of casprintf? (I use the
mingw-installation from Fedora to cross-compile to mingw)

Joost van der Sluis.
Permalink | Reply | 6 comments |
headers
Mark Kettenis | 3 Oct 2011 12:07
Picon
Picon
Favicon

Re: Crash of Archer's gdb on mingw (passing null argument to vasprintf)

> From: Joost van der Sluis <joost <at> cnoc.nl>
> Date: Mon, 03 Oct 2011 11:39:37 +0200
> 
> Hi all,
> 
> Maybe a strange question because it's not about stock gdb but about the
> fedora16-branch from the Archer project. But I know that there are not
> that much mingw/Windows people on the Archer mailinglist, so I ask here.
> 
> In gdbtypes.c there's this code:
> 
>     warning (_("Range for type %s has invalid bounds %s..%s"),
>             TYPE_NAME (type), plongest (TYPE_LOW_BOUND (range_type)),
>             plongest (TYPE_HIGH_BOUND (range_type)));
> 
> This goes wrong when TYPE_NAME (type) is null. Eventually warning()
> leads to a call of vasprintf(), and on Fedora it prints '(NULL)' when it
> encounters a null-parameter. But on mingw it crashes (sigint).
> 
> How to fix this properly? I could add a check for the assignment of
> TYPE_NAME (type). Or should mingw fix their vasprintf implementation? Or
> can I switch to another version of casprintf? (I use the
> mingw-installation from Fedora to cross-compile to mingw)

The C standard doesn't say that printf("%s", NULL) should be treated
specially, so having things crash just as the would for printf("%s",
p) where p is an invalid pointer is perfectly fine.  So blindly
printing TYPE_NAME (type) clearly is the problem here.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Brobecker | 3 Oct 2011 16:59
Favicon

Re: Crash of Archer's gdb on mingw (passing null argument to vasprintf)

> In gdbtypes.c there's this code:
> 
>     warning (_("Range for type %s has invalid bounds %s..%s"),
>             TYPE_NAME (type), plongest (TYPE_LOW_BOUND (range_type)),
>             plongest (TYPE_HIGH_BOUND (range_type)));
> 
> This goes wrong when TYPE_NAME (type) is null.

We should several example of us handling this type of situation.
Typically we use:

        TYPE_NAME (type) ? TYPE_NAME (type) : "<anonymous>"

or something like that.
--

-- 
Joel
Permalink | Reply | 4 comments |
headers
Joost van der Sluis | 3 Oct 2011 18:16
Picon
Favicon

Re: Crash of Archer's gdb on mingw (passing null argument to vasprintf)

On Mon, 2011-10-03 at 07:59 -0700, Joel Brobecker wrote:
> > In gdbtypes.c there's this code:
> > 
> >     warning (_("Range for type %s has invalid bounds %s..%s"),
> >             TYPE_NAME (type), plongest (TYPE_LOW_BOUND (range_type)),
> >             plongest (TYPE_HIGH_BOUND (range_type)));
> > 
> > This goes wrong when TYPE_NAME (type) is null.
> 
> We should several example of us handling this type of situation.
> Typically we use:
> 
>         TYPE_NAME (type) ? TYPE_NAME (type) : "<anonymous>"

I've found the TYPE_ERROR_NAME macro. Now another question: how do I
send a patch for inclusion in gdb? Can I send it to this list? Or
gdb-patches?

btw: patch is attached. First part will only apply to Archer though. (My
guess is the archer-jankratochvil-vla branch)

Regards,

Joost van der Slui
Attachment (TYPE_NAME_fix.diff): text/x-patch, 998 bytes
Permalink | Reply | 3 comments |
headers
Joel Brobecker | 3 Oct 2011 18:25
Favicon

Re: Crash of Archer's gdb on mingw (passing null argument to vasprintf)

> I've found the TYPE_ERROR_NAME macro.

Heh - I didn't know about this one.

> Now another question: how do I send a patch for inclusion in gdb? Can
> I send it to this list? Or gdb-patches?

It is preferable that you submit patches upstream if they apply there.
In that case, please send them to gdb-patches.  If they only apply
to project Archer, then you should send them to the archer list.

You should review the contents of the gdb/CONTRIBUTE file, which gives
the initial pointers on how to submit a patch.  You're not far off
in this case, but you are missing a ChangeLog entry.

You might also want to start a copyright assignment process if you
are planning on contributing again. We can take one, or maybe two
small patches, but beyond that, we almost always require that
the contributor have an assignment on file.

--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Jan Kratochvil | 3 Oct 2011 18:34
Picon
Favicon

Re: Crash of Archer's gdb on mingw (passing null argument to vasprintf)

On Mon, 03 Oct 2011 18:16:38 +0200, Joost van der Sluis wrote:
> btw: patch is attached. First part will only apply to Archer though. (My
> guess is the archer-jankratochvil-vla branch)

I have applied it to archer-jankratochvil-vla
(fb9d144c4cb4152a1e20e8fecf58ff556fd110d6).

Still the second part needs to go through the standard FSF GDB contribution
process, as suggested by Joel.

Thanks,
Jan
Permalink | Reply | 0 comments |
headers
Lurkos | 4 Oct 2011 20:51
Picon

Re: cannot print allocatable arrays

*Jan Kratochvil* wrote:

>> I'm using gdb 7.0.1-debian and gfortran 4.4.5 on Debian squeeze amd64.
>> 
>> I'm not able to print arrays that are declared as allocatable.
>
> This works in archer-jankratochvil-vla branch
> 	http://sourceware.org/gdb/wiki/ArcherBranchManagement
> and Fedora GDBs; even there it has some limitations for complicated data
> structures but in general it works.
>
> Not sure when it gets merged, it needs to be mostly rewritten.  There are
> AFAIK also some independent efforts for this feature for GDB.

I have almost zero experience with git.
I read GDB wiki and also a couple of howtos about git.
I'm not sure if I have to clone gdb repository
(git://sourceware.org/git/gdb.git) or archer
(git://sourceware.org/git/archer.git) to merge archer-jankratochvil-vla
branch into mainline.

Can you please give me just a couple of hints and/or a suggestion of a
good reference to get started with git?

Thank!

--

-- 
Lurkos
(Continue reading)

Permalink | Reply | 1 comment |

Gmane