From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Russ.Shaw" To: Michael Sokolov Cc: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: An article about the Cygnus tree Date: Tue, 05 Sep 2000 16:13:00 -0000 Message-id: <39B57E79.EADD4317@webaxs.net> References: <0009051753.AA02054@ivan.Harhan.ORG> X-SW-Source: 2000-09/msg00042.html 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" 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 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 > Date: Tue, 5 Sep 2000 15:33:54 +0200 (MET DST) > From: Mark Kettenis > > 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 To: Eli Zaretskii 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" > > > > 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 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 To: "H . J . Lu" Cc: Mark Kettenis , 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" To: Stan Shebs Cc: Mark Kettenis , 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 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 To: drepper@cygnus.com (Ulrich Drepper), Daniel Berlin Cc: Mark Kettenis , 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: 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