Re: An article about the Cygnus tree

["Russ.Shaw" <russell@webaxs.net>]

Its just that crossgcc traffic seems a bit on the low side
for some reason. BTW, is all this cross-posting bad? A
newsgroup is better suited for a wide range of questions
and seems more 'publicly accessible' for beginners to
ask all kinds of stupid questions.

Michael Sokolov wrote:
> 
> "Russ.Shaw" <russell@webaxs.net> wrote:
> 
> > I think there should be a newsgroup for the gnu tools etc, for applications
> > involving embedded systems. comp.arch.embedded is more hardware oriented.
> > What about a comp.gnu.embedded for all questions on installation, development,
> > use, and abuse of gnu/cygnus/open-source tools for embedded systems?
> 
> How is the crossgcc mailing list not enough for you for this purpose? That's
> exactly what it's for.

-- 
*******************************************
*   Russell Shaw, B.Eng, M.Eng(Research)  *
*      email: russell@webaxs.net          *
*      Victoria, Australia                *
*******************************************
From kettenis@wins.uva.nl Tue Sep 05 17:06:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 17:06:00 -0000
Message-id: <200009060006.e8606og01806@delius.kettenis.local>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> <200009051546.LAA06234@indy.delorie.com>
X-SW-Source: 2000-09/msg00043.html
Content-length: 2540

   Date: Tue, 5 Sep 2000 11:46:48 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   > Date: Tue, 5 Sep 2000 15:33:54 +0200 (MET DST)
   > From: Mark Kettenis <kettenis@wins.uva.nl>
   > 
   > I was thinking of having some sort of register cache for the
   > debugging registers but didn't immedeately see the right solution to
   > do that.  Perhaps they should simply be added to the register cache?

   I think all we need is to store the debug registers somewhere.  They
   need to be accessed by (1) the x86-dependent code which is called by
   GDB's application level to insert and remove watchpoints; (2) the
   target-specific code which actually calls ptrace or the equivalent
   syscall to pass the values into the inferior's registers before
   resuming it, and set bits after the inferior stops to indicate which
   watchpoint(s) triggered; and (3) by stopped_by_watchpoint's target
   end.

   It's possible that the register cache is as good place as any to store
   DRi, even though they slightly differ from the rest of the registers.

Yep, and that's where I got distracted by more urgent problems :-(.

   > I also couldn't directly see how the hardware watchpoint supports
   > interacts with multiple threads

   Sorry, I'm not sure I see the problem.  Could you please elaborate?
   (I'm afraid I don't know much about Linux threads.)

Me neither :-(.  I'm not sure whether the debug registers are
per-thread or per-VM-space in Linux.  I'll probably need to look into
the kernel source.

   > especially in presence of the nifty way the go32 code maps multiple
   > waitchpoints on a single debugging register.

   I don't think this should matter.  The reference counts are just a
   means to know which register is used and which isn't.  As far as the
   higher-level GDB code is concerned, what's important is (a) which
   address, if any, triggered a watchpoint; and (b) which thread caused
   the watchpoint to trigger.

If you can set the debug registers per-thread, we might need a
reference count for every thread.  If the debug registers are
per-VM-space there might be a potential problem with finding out the
right triggering address for the right thread.

   However, if I'm missing the point, and there's some additional
   infrastructure that is required to make this work with multiple
   threads, please tell what is, or might be, missing.

It's something that needs to be investigated.  But since DJGPP doesn't
seem to support multiple threads I certainly don't expect you to do
that :-).

Mark
From shebs@apple.com Tue Sep 05 18:02:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:02:00 -0000
Message-id: <39B59772.F3E69072@apple.com>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com>
X-SW-Source: 2000-09/msg00044.html
Content-length: 1397

Eli Zaretskii wrote:
> 
> >   Date: Mon, 4 Sep 2000 23:32:22 -0700
> >   From: "H . J . Lu" <hjl@lucon.org>
> >
> >   If you can generalize it for ia32, I will implement it for Linux/ia32.
> 
> The code on go32-nat.c manipulates an array which represents the ia32
> debug registers, including the status and control registers.  It
> leaves it to resume() and its subroutines on the target end to
> actually insert the watchpoints when the inferior is resumed and
> remove them when the inferior stops and control is passed to GDB.
> 
> If this model suits most or all ia32 targets, pulling the code from
> go32-nat.c into a separate module (probably, as part of i386-nat.c)
> would be very easy for me.  If not, I'd ask the relevant maintainers
> to tell what provisions should I make for other platforms to fit in.
> 
> >   If it won't be fixed in 5.1, I will follow your hints and implement a
> >   Linux only solution when it happens to me again.
> 
> I can do this Very Soon (tm) provided that I hear a GO from The Powers
> That Be.  Andrew?  Stan?  What say you?

Uh, is there any reason not to?  We tell people that GDB can support
h/w watchpoints, seems like we ought to deliver it on our most popular
platforms.  Perhaps I could be evil and insist on adding a testsuite test
that would take 24 hours to run if h/w watchpoints don't work... think
that would help motivate anyone? :-)

Stan
From jason-swarelist@molenda.com Tue Sep 05 18:21:00 2000
From: Jason Molenda <jason-swarelist@molenda.com>
To: scottb@netwinder.org, hjl@lucon.org, nickc@redhat.com, gdb@sources.redhat.com
Subject: Re: src/ltcf-c.sh
Date: Tue, 05 Sep 2000 18:21:00 -0000
Message-id: <20000905182042.A7301@shell17.ba.best.com>
X-SW-Source: 2000-09/msg00045.html
Content-length: 1400

I haven't been following this thread, but...

scottb> Actually on further testing, it gets me the file on checkout, but not
scottb> on an update.

hjl> You have to use checkout on binutils and gdb.

It isn't all that horrible.  A 'checkout' will act like an update if the
tree is already populated by files.

If you normally do

 % cd /somewhere/src
 % cvs update

do this instead:

 % cd /somewhere
 % cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb
 % cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co binutils

and you'll see it pulling over only the new/updated files/directories
in to your tree.

It is a bit less efficient to use a checkout instead of an update.
The update will send deltas (patches) over the wire to update your
work area, whereas a checkout sends the files in their entirety.

In either case, compressing the cvs operation is always a good
idea. Add  the '-z9' command line option directly after 'cvs',
or put

  cvs -q -z9

in your $HOME/.cvsrc.


Jason

PS-  If you guys are talking about a file in the top-level directory,
then a checkout is not necessary, an update will pick it up.  The only
thing an update won't get you are newly created directories.  If an
update _isn't_ getting some file, I'd look over your CVS/Entries file
in that directory to see if there might be something in there that is
confusing cvs.  This behavior does not sound correct.
From shebs@apple.com Tue Sep 05 18:23:00 2000
From: Stan Shebs <shebs@apple.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:23:00 -0000
Message-id: <39B59C92.37799057@apple.com>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> <20000905084923.C15547@lucon.org>
X-SW-Source: 2000-09/msg00046.html
Content-length: 1625

"H . J . Lu" wrote:
> 
> On Tue, Sep 05, 2000 at 03:33:54PM +0200, Mark Kettenis wrote:
> >
> >    >   If it won't be fixed in 5.1, I will follow your hints and implement a
> >    >   Linux only solution when it happens to me again.
> >
> > A generic x86 solution would be preferable, but a clean, well
> > documented Linux-only solution is certainly welcome.
> 
> Given do it clean, do it fast and make it to work, you can only
> pick 2 if I am the only one to do it. Since I don't have much time
> to do it, I have to pick do it fast.

I feel like I should say something here - doing things fast for GNU/Linux
has been a continuing source of problems.  All this stuff is going
to take the same amount of time in the end, whether we kludge now and
rewrite over and over later, or do it right the first time.  GDB Linux
thread hacking has been going on for a couple years, and it's still not
quite done; if I had known it was going to take this long, I would
have taken a harder line about accepting the original expedient version.

If you don't think that you're getting enough time to do things right,
then you should take it up with your management.  Since VA Linux thinks
highly enough of you to feature your picture prominently in their Linux
World booth :-), you should have enough pull to say "this is how long
it needs to take".  If you supply me with names, I will be happy to
take it up with them myself too - VA Linux' business depends heavily on
its reputation for good Linux engineering, and I doubt they want to
become known as the company that is pushing hacky forked versions of GDB
out into the world.

Stan
From hjl@lucon.org Tue Sep 05 18:33:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Stan Shebs <shebs@apple.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:33:00 -0000
Message-id: <20000905183312.A17823@lucon.org>
References: <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> <20000905084923.C15547@lucon.org> <39B59C92.37799057@apple.com>
X-SW-Source: 2000-09/msg00047.html
Content-length: 763

On Tue, Sep 05, 2000 at 06:23:31PM -0700, Stan Shebs wrote:
> 
> If you don't think that you're getting enough time to do things right,
> then you should take it up with your management.  Since VA Linux thinks

The gdb work has nothing to do with my job at VA :-). I don't even
know they are aware of it. I only work on gdb because I don't want to
wait for a few hours when debugging the code nor start all over when
I use up all hardware registers. If it is a must-fix for gdb 5.1, I
am willing to pitch in. If noone else wants to spend time on it, I
will come up with some kludge for myself.

BTW, it has been a long standing problem for gdb. It seems that I
am the only one who thinks gdb sucks under Linux/ia32 and is willing
to do something about it.


H.J.
From jason@molenda.com Tue Sep 05 19:08:00 2000
From: Jason Molenda <jason@molenda.com>
To: scottb@netwinder.org, hjl@lucon.org, nickc@redhat.com, gdb@sources.redhat.com
Subject: Re: src/ltcf-c.sh
Date: Tue, 05 Sep 2000 19:08:00 -0000
Message-id: <20000905190824.A14877@shell17.ba.best.com>
References: <20000905182042.A7301@shell17.ba.best.com>
X-SW-Source: 2000-09/msg00048.html
Content-length: 971

I looked into this a bit (after sending my mail note saying there should
be no problem, of course :-).  I can reproduce Scott's reported problem.

An update with the an SSH or pserver access methods does not pick
up files added in the src/ directory.  I honestly don't know why.

It doesn't have anything to do with the modules file - that file
is only relevant at check-out time; after that, cvs knows nothing
of the module you checked out.

I poked around trying to figure out what is going on this this
directory, but failed (or rather, I have to get back to my real
work :-).  For what it's worth, though, this behavior we're seeing
with the top level of the /cvs/src directory is neither expected
nor correct.  Something is up with the RCS files here.  Or maybe
there is some odd case of cvs that I don't understand and it's
coming up here, but that's not as likely.

As people have suggested, check out binutils/gdb again from the top
level as a workaround.

Jason
From kevinb@cygnus.com Tue Sep 05 19:12:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: drepper@cygnus.com (Ulrich Drepper), Daniel Berlin <dan@cgsoftware.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, hjl@lucon.org, amylaar@cygnus.co.uk, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 19:12:00 -0000
Message-id: <1000906021234.ZM22676@ocotillo.lan>
References: <Pine.LNX.4.21.0009041104140.3814-100000@propylaea.anduin.com> <m33djg81kh.fsf@otr.mynet.cygnus.com> <drepper@redhat.com>
X-SW-Source: 2000-09/msg00049.html
Content-length: 5036

On Sep 4, 11:16am, Ulrich Drepper wrote:

> > i forwarded them along to various gdb people, but the consensus was
> > that it didn't actually fix the real problem.
> 
> Well, then fix it correctly.  I'm using the patches for years without
> experiencing negative side effects.  Only with them is it possible to
> debug ld.so.

I took a look at these patches in late July in the hope that they
would fix some problems that I was seeing (on a not-to-be-named
platform) with relocating the main executable.  Below is a portion of
a message that I sent to one of the internal Red Hat lists concerning
Uli's solib.c patches.  In order to make sense of some of my comments,
it helps to know that I needed the read-only and read/write sections
to be relocated by different amounts.  This isn't terribly relevant
for the discussion at hand, but I think that any solution we come
up with needs to handle this case.  (My comments immediately preceding
Uli's patch *are* relevant though.)

......................................................................

I tried them and they didn't work for me.  There are several problems
with these patches for my situation:

    1)  The exec_bfd isn't marked DYNAMIC.  (But the OS is relocating
	it anyway; according to the ABI, this is okay.) Anyway, since
	it isn't marked DYNAMIC, Uli's code for relocating the symbols
	doesn't get a chance to run.

    2)  The stop_pc when this code is hit is at the _start symbol in
        the dynamic linker.  But I want to relocate the main executable
	whose _start symbol hasn't been hit yet.

    3)  Even if the preceding two problems could be reconciled, the
        .text and .data sections need to be relocated by different
	amounts.

[...]

I'm going to back out Uli's patch from my sandbox.  It didn't build
cleanly in my sandbox, so I'm posting below a cleaned up version which
does build.  We'll need to incorporate something like this into gdb at
some point.  Before we do though, I'd like to understand why the
changes to breakpoint.c are necessary.  Also, we need to consider the
situation where exec_bfd is not the dynamic linker, but is marked
DYNAMIC for some reason.  If this should happen, Uli's code will get
hit and the symbols in exec_bfd / symfile_objfile will get improperly
relocated.

Index: solib.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/solib.c,v
retrieving revision 1.146
diff -u -p -r1.146 solib.c
--- solib.c	2000/05/28 01:25:33	1.146
+++ solib.c	2000/07/26 17:50:36
@@ -54,6 +54,7 @@
 #include "environ.h"
 #include "language.h"
 #include "gdbcmd.h"
+#include "objfiles.h"
 
 #define MAX_PATH_SIZE 512	/* FIXME: Should be dynamic */
 
@@ -1984,6 +1985,39 @@ solib_create_inferior_hook ()
     {
       warning ("shared library handler failed to enable breakpoint");
       return;
+    }
+
+  if ((bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
+      && bfd_get_start_address (exec_bfd) != stop_pc)
+    {
+      /* We have to relocate the debug information.  */
+      static CORE_ADDR last_displacement;
+      CORE_ADDR displacement = stop_pc - exec_bfd->start_address;
+
+      if (last_displacement != displacement)
+	{
+	  CORE_ADDR correction = displacement - last_displacement;
+	  struct section_offsets *new_offsets;
+	  int i;
+
+	  new_offsets = alloca (symfile_objfile->num_sections
+				* sizeof (*new_offsets));
+
+	  for (i = 0; i < symfile_objfile->num_sections; ++i)
+	    ANOFFSET (new_offsets, i) =
+	      ANOFFSET (symfile_objfile->section_offsets, i);
+
+	  ANOFFSET (new_offsets, SECT_OFF_TEXT (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_DATA (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_BSS (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_RODATA (symfile_objfile)) += displacement;
+
+	  objfile_relocate (symfile_objfile, new_offsets);
+	  breakpoint_re_set ();
+
+	  /* Remember the current displacement.  */
+	  last_displacement = displacement;
+	}
     }
 
 #if !defined(SVR4_SHARED_LIBS) || defined(_SCO_DS)
Index: breakpoint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/breakpoint.c,v
retrieving revision 1.294
diff -u -p -r1.294 breakpoint.c
--- breakpoint.c	2000/06/04 00:35:16	1.294
+++ breakpoint.c	2000/07/26 17:50:44
@@ -7108,6 +7108,7 @@ breakpoint_re_set_one (bint)
       return 0;
     case bp_breakpoint:
     case bp_hardware_breakpoint:
+    case bp_shlib_event:
     case bp_catch_load:
     case bp_catch_unload:
       if (b->addr_string == NULL)
@@ -7246,10 +7247,6 @@ breakpoint_re_set_one (bint)
 
       /* This breakpoint is special, it's set up when the inferior
          starts and we really don't want to touch it.  */
-    case bp_shlib_event:
-
-      /* Like bp_shlib_event, this breakpoint type is special.
-	 Once it is set up, we do not want to touch it.  */
     case bp_thread_event:
 
       /* Keep temporary breakpoints, which can be encountered when we step