On Tue, Nov 11, 2014 at 5:03 AM, Siva Chandra wrote:
> On Tue, Nov 11, 2014 at 3:38 AM, Jonathan Wakely wrote:
>> On 10/11/14 21:49 +, Jonathan Wakely wrote:
>>>
>>> On 09/11/14 16:00 -0800, Siva Chandra wrote:
>>>>
>>>> Hello,
>&g
On Tue, Nov 11, 2014 at 3:38 AM, Jonathan Wakely wrote:
> On 10/11/14 21:49 +, Jonathan Wakely wrote:
>>
>> On 09/11/14 16:00 -0800, Siva Chandra wrote:
>>>
>>> Hello,
>>>
>>> Attached is a patch which adds xmethods for the associative c
implements xmethods for size and empty. That way, it is a fairly
straightforward patch.
libstdc++-v3/ChangeLog:
2014-11-09 Siva Chandra Reddy
* python/libstdcxx/v6/xmethods.py: Add xmethods for associative
containers.
* testsuite/libstdc++-xmethods/associative-containers.cc
On Mon, Oct 13, 2014 at 4:23 AM, Jonathan Wakely wrote:
> On 12/10/14 06:49 -0700, Siva Chandra wrote:
>>
>> Hello,
>>
>> Attached is a patch which adds xmethods for std::array, std::deque,
>> std::forward_list, std::list and std::vector. There were already
>&
Hello,
Attached is a patch which adds xmethods for std::array, std::deque,
std::forward_list, std::list and std::vector. There were already
couple of xmethods existing for std::vector, but this patch adds more
over them.
libstdc++-v3/ChangeLog:
2014-10-12 Siva Chandra Reddy
> to solve the inferior function call issue.
Triviality (or not) is specified by the language. Similarly, the
'this' pointer is specified by the language. However, function calling
convention is specified by the ABI. ISTR that DWARF cannot/should not
describe the ABI. May be I am wrong, but if it is indeed possible to
specify the ABI in DWARF, then I agree that it probably is the best
solution for function call issue.
Thanks,
Siva Chandra
On Mon, Oct 6, 2014 at 5:55 PM, Jason Merrill wrote:
> On 10/06/2014 08:50 PM, Siva Chandra wrote:
>> But, the question is whether it is required to determine the parameter
>> passing ABI. If there is no special marker to indicate that the user
>> declared 'tor is expl
On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill wrote:
> On 10/03/2014 05:41 PM, Siva Chandra wrote:
>>
>> I understand that knowing whether a copy-ctor or a d-tor has been
>> explicitly defaulted is not sufficient to determine the parameter
>> passing ABI. However,
ary? I could be wrong, but
doesn't the example I have given show that it is necessary?
Thanks,
Siva Chandra
te attribute for it? The (small)
> advantage of having a separate attribute is that the consumer knows
> whether it was explicitly defaulted.
It might still be of value, may be to answer questions like "why is
the member marked as artificial?".
gcc/cp/ChangeLog:
2014-10-03 Siva Chand
On Fri, Oct 3, 2014 at 10:13 AM, Siva Chandra wrote:
> On Fri, Oct 3, 2014 at 7:17 AM, Jason Merrill wrote:
>> On 10/03/2014 09:12 AM, Mark Wielaard wrote:
>>>
>>> A debugger not knowing whether a special member function was explicitly
>>> defaulted, impli
is a function
defined as:
A
make_a (int i)
{
A a;
a.a = i;
return a;
}
Then, if a user invokes make_a at the GDB prompt, then GDB will
wrongly pass the pointer to the return value as a hidden first
parameter.
Question: Should special member functions declared = default be marked
DW_AT_artificial?
Thanks,
Siva Chandra
. The
attached patch removes all code which explicitly loads the hooks from
hook.in.
2014-09-29 Siva Chandra Reddy
* python/hook.in: Only import libstdcxx.v6.
* python/libstdcxx/v6/__init__.py: Load printers and xmethods.
diff --git a/libstdc++-v3/python/hook.in b/libstdc++-v3
On Wed, Sep 10, 2014 at 6:18 AM, Jonathan Wakely wrote:
> I've committed the v5 patch to trunk now.
Thanks a lot.
> It would be nice to address Tom's comment at some future time, so we
> only have one entry point in the hook.in file.
I will do it before I add more xmet
On Wed, Sep 3, 2014 at 3:47 PM, Siva Chandra wrote:
> On Wed, Sep 3, 2014 at 3:35 PM, Jonathan Wakely wrote:
>> I was waiting to see which version of the patch actually works, so
>> that users can use the xmethods. There's no point committing the patch
>> if they are
asked if it can
be addressed as a follow up. It seems to me like his suggestion is a
code cleanup, but I am not really sure what the aim of the cleanup is.
To avoid mixing up discussing that versus the aim the patch in
question, I am asking if it can addressed as a follow up.
Thanks,
Siva Chandra
Ping. I am not sure if the "OK to ping weekly" applies to GCC patches
as well. I apologize if it has to be longer.
On Wed, Aug 27, 2014 at 3:58 PM, Jonathan Wakely wrote:
> On 27 August 2014 23:38, Siva Chandra wrote:
>> You are probably already doing it, but just in case
cc's install-relocatability requirement.
OK. Do you think I could do this as a follow up? May be not
considerable, but seems to me like it distracts the intent of this
patch?
Thanks,
Siva Chandra
am probably not understanding it right again. Are you suggesting
that in hook.in, we just have single function call like this:
register_python_hooks (gdb.current_objfile ())
and, this function register_python_hooks lives somewhere else and
calls register_libstdcxx_printers and register_libstdcxx_xmethods?
Thanks,
Siva Chandra
n here is that I think it's better to have a single
> registration function in the libstdc++ python code. This function can
> do all the needed work.
My patch is still using a single function to register libstdc++
xmethods. Do you mean there should be a single function for pretty
printers and xmethods together?
Thanks,
Siva Chandra
ly are as otherwise the tests
added by this patch will not be exercised.
Thanks,
Siva Chandra
On Wed, Aug 27, 2014 at 3:31 PM, Tom Tromey wrote:
>>>>>> "Siva" == Siva Chandra writes:
>
> Siva> I had something in hook.in in my very first patch but Tom Tromey said
> Siva> it was not required anymore:
> Siva> https://gcc.gnu.org/ml/gcc-patche
xmethods, GDB will
print something like "No matching method for
unique_ptr<...>::operator* found" if those operators were not used in
the source.
ChangeLog:
2014-08-27 Siva Chandra Reddy
* python/hook.in: Load the xmethods.
* python/Makefile.am (noba
Friendly ping.
On Wed, Aug 13, 2014 at 7:50 AM, Jonathan Wakely wrote:
> On 13 August 2014 14:55, Siva Chandra wrote:
>> Ping. Any update on this?
>
> No, I haven't committed it yet, but I will get round to it.
>
>> On Wed, Aug 6, 2014 at 6:37 AM, Siva Chandra wrot
Ping. Any update on this?
On Wed, Aug 6, 2014 at 6:37 AM, Siva Chandra wrote:
> On Wed, Aug 6, 2014 at 2:47 AM, Jonathan Wakely wrote:
>> Some GNU/Linux distros already build GDB using Python3, so they will
>> be unable to use these xmethods.
>>
>> However, I think
On Wed, Aug 6, 2014 at 2:47 AM, Jonathan Wakely wrote:
> Some GNU/Linux distros already build GDB using Python3, so they will
> be unable to use these xmethods.
>
> However, I think it can be committed now and fixed later.
For the libstdc++ side, it is a very small fix (using 'print' with
functio
Hi Jonathan,
Thanks a lot for taking a look. The patch in question, and the GDB
support, do not yet work with Python3. If that is a necessary
requirement, I can make the changes and send a new version of the
patch.
Thanks,
Siva Chandra
On Mon, Aug 4, 2014 at 2:36 AM, Jonathan Wakely wrote
more xmethods in place.
Link to v1 posting: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02339.html
Link to v2 posting: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg2.html
ChangeLog
2014-07-25 Siva Chandra Reddy
* python/libstdcxx/v6/xmethods.py: New file.
* testsuite
Ping.
On Mon, Jun 30, 2014 at 6:07 PM, Siva Chandra wrote:
> On Mon, Jun 30, 2014 at 8:00 AM, Tom Tromey wrote:
>>>>>>> "Siva" == Siva Chandra writes:
>>
>> Siva> +# Load the xmethods.
>> Siva> +from libstdcxx.v6.xmethods import registe
On Mon, Jun 30, 2014 at 8:00 AM, Tom Tromey wrote:
>>>>>> "Siva" == Siva Chandra writes:
>
> Siva> +# Load the xmethods.
> Siva> +from libstdcxx.v6.xmethods import register_libstdcxx_xmethods
> Siva> +register_libstdcxx_xmethods (gdb.current_objfi
and std::unique_ptr. One can of
course add xmethods to many other classes, but I am viewing this as
the first patch in that series (though not a series yet) to get the
basic infrastructure for adding more xmethods in place.
ChangeLog
libstdc++-v3/
2014-06-29 Siva Chandra Reddy
* python
Previous post: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00839.html
It was reviewed by Cary, but he said that a C++ front end maintainer
needs to approve it:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00175.html
The patch is attached. I do not have write access.
ChangeLog:
2014-04-21 Siva
. I do not have write access.
ChangeLog:
2014-04-15 Siva Chandra Reddy
Fix PR debug/57519
/cp
PR debug/57519
* class.c (handle_using_decl): Pass the correct scope to
cp_emit_debug_info_for_using.
testsuite/
PR debug/57519
* g++.dg/debug
component.
The patch is attached.
Link to the previous posting:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00587.html
ChangeLog:
2014-03-25 Siva Chandra Reddy
Fix PR debug/57519
/cp
PR debug/57519
* class.c (handle_using_decl): Pass
{
public:
using A::method;
int method (const B &b);
};
int
B::method (const B &b)
{
return b.a + a;
}
Before the patch, the die corresponding to the 'using' statement in
class B was getting emitted as a child of the die corresponding to
class A.
ChangeLog:
20
35 matches
Mail list logo
