is the wrong way, but a while ago the
GDB project (following Glibc's lead) decided that we would
not add more "contributed by", "written by", etc. notes.
See here <https://sourceware.org/gdb/wiki/ContributionChecklist#Attribution>
and follow the link there for rationale.
Thanks,
Pedro Alves
On 09/06/2017 11:11 PM, Samuel Thibault wrote:
> Pedro Alves, on lun. 04 sept. 2017 13:14:33 +0100, wrote:
>> On 08/27/2017 07:41 PM, Samuel Thibault wrote:
>>> Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
>>> rights.'), some R
ng ToT gdb on
non-ToT Hurd systems? Is the intention to only ever support building
ToT gdb with ToT Hurd?
Thanks,
Pedro Alves
>
> diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> index d5e3841e68..402027866b 100644
> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -1874,17 +1876,19 @@ ILL_
with a cleanup:
char *pathname = (char *) xmalloc (pathlen + 1);
struct cleanup *old_chain = make_cleanup (xfree, pathname);
hex2bin (p1, (gdb_byte *) pathname, pathlen);
pathname[pathlen] = '\0';
discard_cleanups (old_chain);
OK with that change.
Thanks,
Pedro Alves
On 01/08/2014 09:20 PM, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 24 Oct 2013 16:17:21 +0100, Pedro Alves wrote:
>> Here's what I pushed
>
> ..., and what made the Hurd port pretty unhappy. ;-)
Whoops. ;-) Thanks for fixing.
> In the thread around
> <
e the rationale for the changes end up in the commit log).
Thanks,
--
Pedro Alves
On 09/20/2013 01:43 AM, David Michael wrote:
> Hi,
>
> (Copying gdb-patches this time.)
But, we're missing all the context on the gdb-patches@ side.
>
> Here is an updated patch to successfully build GDB after today's
> Hurd/mig changes.
--
Pedro Alves
On 09/19/2013 09:30 AM, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 19 Sep 2013 15:40:40 +0800, Yue Lu wrote:
>> On Wed, Sep 18, 2013 at 8:37 PM, Pedro Alves wrote:
>>> On 09/12/2013 04:05 AM, Yue Lu wrote:
>>>
>>>> On Sat, Sep 7, 2013 at 2:53 AM, Ped
ur editor or mailer?)
line-wrapped the patch. I just now tried saving the
whole email as an mbox file, and then applied it to a pristine
tree with "git am", and saw no issues.
--
Pedro Alves
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 does
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 you
GDB to select a no-longer-existing-thread
(though I can't see how in the current code), and then setting
breakpoints, or other operations that require reading memory
would crash.
--
Pedro Alves
ld and ptid_get_tid in *gnu* files, and
adjusted all I found.
---
Subject: [PATCH] [Hurd/gnu-nat.c] Use ptid_t.lwpid to store thread ids
instead of ptid_t.tid.
In preparation for reusing gnu-nat.c in gdbserver, switch to storing
thread ids in the lwpid field of ptid_t rather than in the
Hi!
On 09/05/2013 08:29 PM, Pedro Alves wrote:
>> > +static int
>> > +gnu_read_memory (CORE_ADDR addr, unsigned char *myaddr, int length)
>> > +{
>> > + int ret = 0;
>> > + task_t task = (gnu_current_inf
>> > + ? (gnu_current_inf-
On 09/05/2013 11:53 AM, Yue Lu wrote:
> Hi,
>
> This is the my new patch.
Thanks. Follows a few comments, by no means an in depth review.
We'll probably need to iterate a few times. I'm counting on
Thomas and others to help as well!
I'm actually very excited to see gdb and gdbserver sharing
a
on gdbserver,
wrapped in #ifndef GDBSERVER. After that initial work is committed,
we can then easily progress the gdbserver port by just looking for
those #ifdefs.
It's fine with me to leave the existing native files under gdb/ while
doing this; it's probably easier that way. Moving them under gdb/nat/
can be left for a cleanup step further down the road.
Could we try that approach?
--
Pedro Alves
/i386/i386gnu.mh, NAT_GENERATED_FILES
in particular, I think gdb will want to run mig even on
cross gdbs hosted on GNU Hurd, though...
--
Pedro Alves
ot;
See <http://www.gnu.org/prep/standards/standards.html#Comments> :
> The comment on a function is much clearer if you use the argument names to
> speak about the
> argument values. The variable name itself should be lower case, but write it
> in
> upper case when you are speaking about the value rather than the variable
> itself.
> Thus, “the inode number NODE_NUM” rather than “an inode”.
--
Pedro Alves
rget) is alright and you removed gnu_can_run just above.
Fixed.
>
> > + t->to_thread_alive = gnu_thread_alive;
> > + t->to_pid_to_str = gnu_pid_to_str;
> > + t->to_stop = gnu_stop;
> > +}
>
> ``return t;'' is missing.
Fixed.
Thanks. I'll commit the patch in a bit.
--
Pedro Alves
ort a bit more into shape for
a future !x86 Hurd port).
What do you think about it? Could you try it if you like it?
--
Pedro Alves
2009-07-20 Pedro Alves
* gnu-nat.c (gnu_mourn_inferior): Use the passed in target_ops
instead of the gnu_ops global.
(gnu_create_inferi
hould be off if there are pending execs.
This was an existing issue, and doesn't affect linux today, so I'll
just ignore that for now, as it needs more tweaking to fix.)
( hope not many issues like this appear, as we're doing more
duplication of handle_inferior_event logic :-( )
Wh
This is missing in the new implementation. In Hurd when going through
the shell doing fork/execs, we see new threads at every exec, and the
old threads disappear. Could you try adding a `switch_to_thread
(resume_thread)'
somewhere after target_wait returns and before any other target method?
--
Pedro Alves
target_resume (resume_ptid, 0, TARGET_SIGNAL_0);
+ target_resume (minus_one_ptid, 0, TARGET_SIGNAL_0);
The other thing I suggest to look at, is to make sure the
local `pending_execs' and the `gnu-nat.c:struct inf'::pending_execs
aren't in conflict, but it doesn't look like it.
Hope this helps.
--
Pedro Alves
data/home/tschwinge/tmp/n1/hurd/ext2fs.static
> Can't fetch registers from thread bogus thread id 1: No such thread
>
> Both have been built (natively) on the same up-to-date Debian GNU/Hurd
> system.
>
> For easy reproduction, I can publish the faulting binary.
>
24 matches
Mail list logo
