Re: CVS build for Solaris 5.8 fails: elfcore_write_prpsinfo undefined

> Undefined                       first referenced
>  symbol                             in file
> elfcore_write_prpsinfo              libgdb.a(procfs.o)
> elfcore_write_prstatus              libgdb.a(procfs.o)
> ld: fatal: Symbol referencing errors. No output written to gdb

I can reproduce. Looks like a problem in the bfd configure script,
as the following check returns "no":

  AC_CHECK_HEADERS(sys/procfs.h)

Extract from the config.log file:

  configure:19338: checking for sys/procfs.h
  configure:19343: result: no

Not much information there. In any case, as a result, the checks
for the various types in procfs.h are skipped:

    BFD_HAVE_SYS_PROCFS_TYPE(prstatus_t)
    BFD_HAVE_SYS_PROCFS_TYPE(prstatus32_t)
    [...]
    BFD_HAVE_SYS_PROCFS_TYPE(prpsinfo_t)
    [etc]

And so HAVE_PRPSINFO_T doesn't get defined as it should.

I have to run, now. I will look deeper into this hopefully tomorrow.

--

-- 

Re: [patch] ia64: Fix breakpoints memory shadow

> I agree your proposal would be better but we have to comply with the current
> `struct bp_target_info' layout which is being intepreted outside of
> ia64-tdep.c - in breakpoint_restore_shadows.
> 
> If we would like to store the whole bundle to SHADOW_CONTENTS we would have to
> store already the base address (`address & ~0x0f') into PLACED_ADDRESS.  In
> such case there is no other place where to store SLOTNUM (`adress & 0x0f',
> value in the range <0..2>).  We need to know SLOTNUM in
> ia64_memory_remove_breakpoint.

Aie aie aie, that's true. I was also looking at the idea of stuffing
the slot number in the first 5 bits of the bundle, but that wouldn't
work either, as breakpoint_restore_shadows can restore those bits
as well. There is one alternative which is to define a gdbarch
restore_shadow, but your approach does work after all, so let's not
complexify the rest of GDB just for ia64.

Can we maybe expand the comment explaining why we can't save the whole
bundle in the shadow buffer?

>  const unsigned char *
>  ia64_breakpoint_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr, int *lenptr)
>  {
> -  static unsigned char breakpoint[] =
> -    { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
> -  *lenptr = sizeof (breakpoint);
> -#if 0
> -  *pcptr &= ~0x0f;
> +  static unsigned char breakpoint[BUNDLE_LEN];
> +  int slotnum = (int) (*pcptr & 0x0f) / SLOT_MULTIPLIER;

Re: CVS build for Solaris 5.8 fails: elfcore_write_prpsinfo undefined

> > Undefined                       first referenced
> >  symbol                             in file
> > elfcore_write_prpsinfo              libgdb.a(procfs.o)
> > elfcore_write_prstatus              libgdb.a(procfs.o)
> > ld: fatal: Symbol referencing errors. No output written to gdb
> 
> I can reproduce. Looks like a problem in the bfd configure script,
> as the following check returns "no":
> 
>   AC_CHECK_HEADERS(sys/procfs.h)

Pedro reminded me that he actually had already seen the problem:
http://sourceware.org/ml/gdb-patches/2008-10/msg00283.html.

The problem is that _FILE_OFFSET_BITS is being defined to 64
in order to provide the capability of handling "large files".
The problem is that procfs on solaris clearly does not work
with the large-file environment activated. The error message
is pretty clear about that, I think:

 #if !defined(_LP64) && _FILE_OFFSET_BITS == 64
 #error  "Cannot use procfs in the large file compilation environment"
 #endif

This problem was introduced when we started using the AC_SYS_LARGEFILES
macro (patch checked in Sep 11). The work-around is to configure GDB
with --disable-largefile.

I'm not sure what the optimal fix should be. Looks like we cannot have
the two features at the same time on Solaris (I checked version 8, 9

Re: CVS build for Solaris 5.8 fails: elfcore_write_prpsinfo undefined

On Sat, Nov 01, 2008 at 03:17:48PM -0700, Joel Brobecker wrote:
> Any other suggestion?

This is clearly a bfd problem - I suggest redirecting the discussion
to the binutils list.

--

-- 
Daniel Jacobowitz
CodeSourcery

[RFA] target adjust pc after break with itself

Hi Pedro,

According to your idea, I write a patch
"target_adjust_pc_with_itself.txt" for it. It's for the main trunk and
20080930 branch.

2008-11-02  Hui Zhu  <teawater <at> gmail.com>

	* target.h (target_ops): Add "to_adjust_pc_with_itself".
	Return true if target adjust pc after break with itself.
	(target_adjust_pc_with_itself): New macro.
	Call "to_adjust_pc_with_itself".
	* target.c (update_current_target): Set
	"to_adjust_pc_with_itself".
	* infrun.c (adjust_pc_after_break): If
	"target_adjust_pc_with_itself" return true, not adjust pc.

To make P record support it. I make another patch
"record_adjust_pc_with_itself.txt".

2008-11-02  Hui Zhu  <teawater <at> gmail.com>

	* record.c (record_adjust_pc_with_itself): New function.
	Return true.
	(init_record_ops): Set to_adjust_pc_with_itself point to
	record_adjust_pc_with_itself.

Thanks,
Hui

[reverse RFC] Record_wait use breakpoint_inserted_here_p

Hi,

This patch just for 20080930 branch.

2008-11-02  Hui Zhu  <teawater <at> gmail.com>

	* record.c (record_wait): Check breakpint before forward
	execute in replay mode.
	Check breakpoint use function "breakpoint_inserted_here_p"
	in replay mode.

Thanks,
Hui

--- a/record.c
+++ b/record.c
 <at>  <at>  -497,6 +497,25  <at>  <at>  record_wait (ptid_t ptid, struct target_
       int continue_flag = 1;
       int first_record_end = 1;
       struct cleanup *old_cleanups = make_cleanup (record_wait_cleanups, 0);
+      CORE_ADDR tmp_pc;
+
+      status->kind = TARGET_WAITKIND_STOPPED;
+
+      /* Check breakpoint when forward execute.  */
+      if (execution_direction == EXEC_FORWARD)
+	{
+	  tmp_pc = regcache_read_pc (regcache);
+	  if (breakpoint_inserted_here_p (tmp_pc))

PING: [PATCH] Fix a bug of addrmap

Hi,

Could someone give a review on this patch:

http://sourceware.org/ml/gdb-patches/2008-10/msg00503.html

Thanks,
Jie

Re: [RFC] Share the shared library list between inferiors

I've checked this in.

--

-- 
Pedro Alves

Re: [RFC] Share the shared library list between inferiors

On Mon, Oct 27, 2008 at 11:29:04PM +0000, Pedro Alves wrote:
> There are several ways to skin this cat.  This one seemed like
> the smallest, most extensible and malleable one from GDB's side, because
> it doesn't cast to stone any new protocol extension --- which may
> prove limited to some systems (some memory regions shared, others not;
> some shared but visible at different addresses in different
> inferiors/cores, etc.).  I was hoping we'd cross that bridge when
> we start seeing those systems reporting multi process support
> to GDB.
> 
> What do people think about this?

I have one request.  Could you expand the comment to mention the other
properties you're associating with this flag?

Global breakpoints and a single common target description don't
obviously follow from "global shared library list".

--

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Share the shared library list between inferiors

On Monday 03 November 2008 14:29:20, Daniel Jacobowitz wrote:
> On Mon, Oct 27, 2008 at 11:29:04PM +0000, Pedro Alves wrote:
> > There are several ways to skin this cat.  This one seemed like
> > the smallest, most extensible and malleable one from GDB's side, because
> > it doesn't cast to stone any new protocol extension --- which may
> > prove limited to some systems (some memory regions shared, others not;
> > some shared but visible at different addresses in different
> > inferiors/cores, etc.).  I was hoping we'd cross that bridge when
> > we start seeing those systems reporting multi process support
> > to GDB.
> > 
> > What do people think about this?
> 
> I have one request.  Could you expand the comment to mention the other
> properties you're associating with this flag?
> 
> Global breakpoints and a single common target description don't
> obviously follow from "global shared library list".

Certainly!  Sorry about that.  That came from the fact that feature
implementation having had several dressings over time, and I guess
I had just started seeing through the name.

I could also rename the gdbarch method to something like
gdbarch_code_is_shared_between_processes, if you'd like (although
it sounds a bit long of a name).

--

-- 
Pedro Alves