On 09/18/2013 02:48 PM, Yue Lu wrote:
> (btw, with
> unknown reason, I can't patch your patch automatically, I have to
> modify the gnu-nat.c line by line according to your patch).
I'm going to guess you copy/pasted the patch to a new file,
and while doing that, something (your editor or mailer?)
On 09/18/2013 02:48 PM, Yue Lu wrote:
> On Wed, Sep 18, 2013 at 8:11 PM, Pedro Alves wrote:
>>
>> /me gives it a try.
>>
>> I grepped for ptid_build and ptid_get_tid in *gnu* files, and
>> adjusted all I found.
>
> I have tried this way before, but it doesn't work.
> After apply your patch, the g
Hi,
On Wed, Sep 18, 2013 at 8:11 PM, Pedro Alves wrote:
> On 09/09/2013 10:58 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu wrote:
>>> On Fri, Sep 6, 2013 at 5:37 AM, Thomas Schwinge
>>> wrote:
> (correct me if
> I'm wrong here), the Hurd's threads a
On 09/12/2013 04:05 AM, Yue Lu wrote:
> On Sat, Sep 7, 2013 at 2:53 AM, Pedro Alves wrote:
>> This is what I meant:
>> https://sourceware.org/ml/gdb-patches/2013-09/msg00253.html
>>
>> I was thinking you'd wrap gnu_xfer_memory.
>>
>
> I have study your patch,
Thanks. Did you try building gdb
On 09/12/2013 04:05 AM, Yue Lu wrote:
> Honestly to say, I have copied them from function gnu_xfer_memory. But
> I think, before reference a pointer, check whether it was a NULL seems
> not a bad way :-).
We don't go around checking for NULL before _every_ pointer
dereference. :-)
NULL pointer c
On 09/09/2013 10:58 AM, Thomas Schwinge wrote:
> Hi!
>
> On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu wrote:
>> On Fri, Sep 6, 2013 at 5:37 AM, Thomas Schwinge
>> wrote:
(correct me if
I'm wrong here), the Hurd's threads are kernel threads
>>>
>>> Correct.
>>>
so it'd
be better
On Wed, Sep 18, 2013 at 07:38:54AM +0200, Marin Ramesa wrote:
> This is more a question than a patch.
>
> Why don't the device pager hash functions use the device server routines to
> track
> the device associated ports?
>
> If the the devices and associated ports are not in one-to-one correspo
