This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GDB 5.1/Core files and ptids


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.


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 

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.


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]