Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Takis Psarogiannakopoulos <takis@XFree86.Org>
To: gdb@sources.redhat.com
Subject: GDB 5.1/Core files and ptids
Date: Wed, 16 Jan 2002 11:16:00 -0000	[thread overview]
Message-ID: <Pine.BSF.4.21.0201161102030.11703-100000@public.xfree86.org> (raw)



Hello,

Trying to port DG/UX source files from gdb 5.0 to version
5.1 (and hopping to submit these at last to GNU) I have found
that there is a serious inconsistency for the BFD core files.

Before one could overload a process pid with a thread id  
using the macro:

#define MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16))

Note that this will give us again an integer!
In 5.1 someone change this to a stucture called ptid. However
it seems to me that you forgot to implemnet something similar
to BFD.

Problem:

Suppose that one has a line co code of the type

sprintf (section_name, "%s/%d", name, inferior_pid);

OR of the type

struct thread_info *tp;
...
sprintf (section_name, "%s/%d", name, tp->pid);

inside  the gdb/core-dgux.c file. Note that this integer 
(tp->pid or inferior_pid) it should contains/be overloaded 
with  the tid too!

Clearly neven if in the 5.1 we have a tp->ptid one cannot 
write 

sprintf (section_name, "%s/%d", name, tp->ptid);

because ptid is now a structure!

Especially when, even in the new gdb-5.1/bfd we find:

======
static int
elfcore_make_pid (abfd)
     bfd *abfd;
{
  return ((elf_tdata (abfd)->core_lwpid << 16)
          + (elf_tdata (abfd)->core_pid));
}
=======

Any suggestions? Eg can the guy that introduced these new
ptids how specicfically to rewrite the line:

sprintf (section_name, "%s/%d", name, tp->pid);

(pid is from 5.0 ie. a mixed pid but still integer!)

having given the tp->ptid and taking in account the 
elfcore_make_pid that is used by bfd!!!

We want to rewrite the bit above so that gdb-5.1 will 
understand! that this section has info about the pid= 
PIDGET(tp->ptid) and the lwp=TIDGET(tp->ptid). And 
reflect these when asked.

Regards,
Takis

PS: My suggestion will be as follows:


#define CORE_BFD_MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16))
(This is just the old gdb 5.0 MERGEPID style).  
  pid_t mixed_bfd_core_pid;

  ... 

  process_pid = PIDGET(tp->ptid);
  process_tid = TIDGET(tp->ptid);

  mixed_bfd_core_pid = CORE_BFD_ERGEPID( process_pid, process_tid);
  sprintf (section_name, "%s/%d", name, mixed_bfd_core_pid);

Would that be OK ? Would gdb-5.1 understand correctly this section?


             reply	other threads:[~2002-01-16 19:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-16 11:16 Takis Psarogiannakopoulos [this message]
2002-01-16 12:53 ` Kevin Buettner
2002-01-17  6:09 Takis Psarogiannakopoulos
2002-01-18 12:26 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.BSF.4.21.0201161102030.11703-100000@public.xfree86.org \
    --to=takis@xfree86.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox