Tom Tromey | 1 Sep 01:09 2009
Picon

Re: =frame-selected MI notification

Nick> I think it would be hard to write a large C program with no global
Nick> variables but, in any case, the concept of current thread/selected
Nick> frame seems to be a great convenience when using GDB from the
Nick> command line.

Volodya> It is convenient for command line GDB usage. This, however,
Volodya> does not mean that global variable that affects all of gdb
Volodya> makes sense.

As long as Emacs and GDB can be in sync, I suppose I don't care much
whether the notification is done by the MI command wrapper or deep in
the guts of GDB.

So, I think we either need Dmitry's patch or Nick's.

I assume we'll find more little holes like this, too.

Tom

Tom Tromey | 1 Sep 01:11 2009
Picon

Re: =frame-selected MI notification

>>>>> "Volodya" == Vladimir Prus <vladimir <at> codesourcery.com> writes:

Volodya> Furthermore, I do not think that observers for either thread or
Volodya> frame changes is good idea, design wise. The fact that gdb has
Volodya> current thread or current frame at the code level, is, IMNSHO,
Volodya> a design bug.

I agree, for the core.  But, the problem in question concerns
notification about the changes to the user's view.

E.g., it wouldn't be unreasonable to want to write a Python script that
reacts to changes in the CLI's notion of frame.  In this case, such an
observer would be useful and appropriate.

Tom

Keith Seitz | 1 Sep 01:19 2009
Picon

Re: [RFA] dwarf2_physname

On 08/31/2009 03:55 PM, Michael Eager wrote:

> Does this mean that (eventually) the DW_AT_MIPS_linkage_name attribute
> will not be needed by GDB?

That is exactly what it is intended to do. MIPS_linkage_name is not 
needed in any case I've been able to invent on my 
archer-keiths-expr-cumulative branch, and that branch has MUCH tougher 
C++ tests than FSF gdb does.

> There was a significant amount of discussion about whether this was
> really needed. There were a couple examples where it might provide
> information which was not otherwise available or where it compensated
> for linkers which didn't support weak externs.

This is the first I've heard of this -- thank you for pointing it out. 
My cursory reading of the proposal leaves me torn about whether this 
really changes anything. I've clearly had better results WITHOUT 
DW_AT_MIPS_linkage_name than with it, but I can imagine how having 
DW_AT_linkage_name for certain special situations might be useful.

Perhaps this might just be the beginning of using DW_AT_linkage_name for 
these "special" situations, as opposed to assuming that every object has 
a DW_AT_linkage_name. I don't know. I guess time will tell.

Keith

Tom Tromey | 1 Sep 01:22 2009
Picon

Re: Simplify MI breakpoint setting

>>>>> "Volodya" == Vladimir Prus <vladimir <at> codesourcery.com> writes:

Volodya> And, progressing recursively, what is the point of not exposing
Volodya> all the parameters of break_command_really?

I don't actually know.  But if I had to guess, I would say it is because
providing wrappers ensures you can't pass in some forms of nonsense.

If you really want to do it, and nobody objects, then I guess I don't
care all that much.  This whole API seems a bit nuts, any time you have
13 arguments you should just assume you've done something wrong already.

I do care about not exporting a function named "break_command_really"
though.

Tom

Michael Eager | 1 Sep 01:34 2009

Re: [RFA] dwarf2_physname

Keith Seitz wrote:
> On 08/31/2009 03:55 PM, Michael Eager wrote:
> 
>> Does this mean that (eventually) the DW_AT_MIPS_linkage_name attribute
>> will not be needed by GDB?
> 
> That is exactly what it is intended to do. MIPS_linkage_name is not 
> needed in any case I've been able to invent on my 
> archer-keiths-expr-cumulative branch, and that branch has MUCH tougher 
> C++ tests than FSF gdb does.
> 
>> There was a significant amount of discussion about whether this was
>> really needed. There were a couple examples where it might provide
>> information which was not otherwise available or where it compensated
>> for linkers which didn't support weak externs.
> 
> This is the first I've heard of this -- thank you for pointing it out. 
> My cursory reading of the proposal leaves me torn about whether this 
> really changes anything. I've clearly had better results WITHOUT 
> DW_AT_MIPS_linkage_name than with it, but I can imagine how having 
> DW_AT_linkage_name for certain special situations might be useful.

The proposal essentially renames DW_AT_MIPS_linkage_name, without
saying very much about how it might be used or why some producers
or consumers might find it necessary.

> Perhaps this might just be the beginning of using DW_AT_linkage_name for 
> these "special" situations, as opposed to assuming that every object has 
> a DW_AT_linkage_name. I don't know. I guess time will tell.

(Continue reading)

Tom Tromey | 1 Sep 01:35 2009
Picon

Re: [RFA] dwarf2_physname

>>>>> "Michael" == Michael Eager <eager <at> eagercon.com> writes:

Michael> (http://www.dwarfstd.org/ShowIssue.php?issue=090715.1&type=closed3)

Michael> There was a significant amount of discussion about whether this was
Michael> really needed.  There were a couple examples where it might provide
Michael> information which was not otherwise available or where it compensated
Michael> for linkers which didn't support weak externs.

I read that page and didn't see these examples.  Do you know where we
could find them?

It seems to me that if we can do the job without DW_AT_*linkage_name,
then all other things being equal that is what we ought to do,
considering that the new attribute is optional.  In practice this only
means that we must determine whether all other things actually are
equal.

Tom

Michael Eager | 1 Sep 02:06 2009

Re: [RFA] dwarf2_physname

Tom Tromey wrote:
>>>>>> "Michael" == Michael Eager <eager <at> eagercon.com> writes:
> 
> Michael> (http://www.dwarfstd.org/ShowIssue.php?issue=090715.1&type=closed3)
> 
> Michael> There was a significant amount of discussion about whether this was
> Michael> really needed.  There were a couple examples where it might provide
> Michael> information which was not otherwise available or where it compensated
> Michael> for linkers which didn't support weak externs.
> 
> I read that page and didn't see these examples.  Do you know where we
> could find them?

They were raised as part of the DWARF Committee discussions:

1)  Finding the address of the in-charge constructor when evaluating
     "new foo()".
2)  Look up address of Fortran common block.
3)  Demangled to display name of instance of overloaded function.
4)  Compensate for compilers which do not generate adequate DWARF.
5)  Demangle to find fully qualified name for type.
6)  Avoid unresolved external references for symbols which are removed
     by the linker, if weak externs are not supported.
7)  Optimize access with Apple's scheme where DWARF is left in the .o's.

Not all of these examples were compelling, nor did it appear that
DW_AT_linkage_name was the only means for obtaining the desired information.
Some were clearly Quality of Implementation issues, like 4.

> It seems to me that if we can do the job without DW_AT_*linkage_name,
(Continue reading)

Paolo Bonzini | 1 Sep 03:09 2009
Picon

Re: obtaining configure args from config.status


> Paolo, we could "fix" this by overriding _AC_INIT_SRCDIR in override.m4,
> but I'm not really sure the old behavior is all that desirable either.
> Instead, I'll try to revive my `config.status --config' patch upstream;
> for the moment, let's parse --version output to get the configuration,
> and add a FIXME note to fix things up later.

I prefer even this patch to overriding. :-)

Paolo

Hui Zhu | 1 Sep 04:15 2009
Picon

Re: [PATCH] Fix cygwin build error with i386-linux-tdep.c

On Mon, Aug 31, 2009 at 23:46, Mark Kettenis<mark.kettenis <at> xs4all.nl> wrote:
>> From: Hui Zhu <teawater <at> gmail.com>
>> Date: Mon, 31 Aug 2009 16:48:33 +0800
>>
>> On Mon, Aug 31, 2009 at 16:45, Jiang Jilin<freephp <at> gmail.com> wrote:
>> >
>> > I think it's not very sensible to cast unsigned to signed, think about
>> > if the unsigned value is _very_ big.
>> >
>>
>> This is syscall id, it will not _very_ big.
>
> Jiang has a point here though.  The cast is weird, and only there
> because it seems you can't make up your mind whether syscall numbers
> are signed or unsigned.  Some bits of code use signed integers and
> some use unsigned integers.  Once that inconsistency is fixed, all
> these problems will disappear.
>
> Mark
>
>

  regcache_raw_read_unsigned (regcache, I386_EAX_REGNUM, &num);

  if (num > 499)
    {
      printf_unfiltered (_("Process record and replay target doesn't "
                           "support syscall number %d\n"), (int) num);
      return -1;
    }
(Continue reading)

Doug Evans | 1 Sep 04:32 2009
Picon

[RFA] Addition to docs, non-stop mode vs remote caching

[resend, typo in address]

Hi.

Ok to check in?

2009-08-31  Doug Evans  <dje <at> google.com>

	* gdb.texinfo (Caching Data of Remote Targets): Add note on
	non-stop mode's affect on remote caching.

Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.619
diff -u -p -r1.619 gdb.texinfo
--- doc/gdb.texinfo	31 Aug 2009 20:18:46 -0000	1.619
+++ doc/gdb.texinfo	1 Sep 2009 02:26:36 -0000
 <at>  <at>  -8427,8 +8427,14  <at>  <at>  performance, because it reduces the over
 bundling memory reads and writes into large chunks.  Unfortunately, simply
 caching everything would lead to incorrect results, since  <at> value{GDBN} 
 does not necessarily know anything about volatile values, memory-mapped I/O
-addresses, etc.  Therefore, by default,  <at> value{GDBN} only caches data
-known to be on the stack.  Other regions of memory can be explicitly marked
+addresses, etc.  Furthermore, in non-stop mode ( <at> pxref{Non-Stop Mode})
+memory can be changed  <at> emph{while} a gdb command is executing.
+Therefore, by default,  <at> value{GDBN} only caches data
+known to be on the stack. <at> footnote{In non-stop mode, it is moderately
+rare for a running thread to modify the stack of a stopped thread
+in a way that would interfere with a backtrace, and caching of
(Continue reading)


Gmane