headers
Andrew Cagney | 25 Apr 2002 18:55
Picon

Re: [Fwd: Cron <gdbadmin <at> sourceware> sh]

> snapshots barfing.
> 
> Just FYI, the nightly snapshot process doesn't like something about the new dejagnu.

And Nick has fixed it.  (thanks)

Andrew
Permalink | Reply | 0 comments |
headers
Andrew Cagney | 25 Apr 2002 19:07
Picon

Re: gdbarch_init called for core files, too?

> So, I'm seeing alpha_gdbarch_init() called twice if I do:
> 
> 	gdb foo foo.core
> 
> ...the first time, alpha_abi is correctly set to ALPHA_ABI_NETBSD, but
> the second time it gets ALPHA_ABI_UNKNOWN.  This means that the wrong
> target-dependent info is being used while debugging the core file.
> 
> This behavior is ... counter-intuitive.  Why is gdbarch_init being called
> for the core file?  Should't it be sufficient to initialize it based on
> the program corresponding to the core file?

There may not necessarily be a program corresponding to the core file: 
gdb --core core.

> ...or should I make the code that looks for ABI tags in note sections to
> also look for "NetBSD-CORE" notes, too?

Sounds right.  I'd check with michael snyder though.

Andrew
Permalink | Reply | 6 comments |
headers
Jason R Thorpe | 25 Apr 2002 19:35

Re: gdbarch_init called for core files, too?

On Thu, Apr 25, 2002 at 01:07:26PM -0400, Andrew Cagney wrote:

 > There may not necessarily be a program corresponding to the core file: 
 > gdb --core core.

Sure, but it doesn't make any sense to do this if there *is* a program
corresponding to the core file.

 > > ...or should I make the code that looks for ABI tags in note sections to
 > > also look for "NetBSD-CORE" notes, too?
 > 
 > Sounds right.  I'd check with michael snyder though.

I looked into this, and I'm not particularly pleased with it as a solution.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 2 comments |
headers
Michael Snyder | 25 Apr 2002 19:59
Picon
Favicon

Re: gdbarch_init called for core files, too?

Andrew Cagney wrote:
> 
> > So, I'm seeing alpha_gdbarch_init() called twice if I do:
> >
> >       gdb foo foo.core
> >
> > ...the first time, alpha_abi is correctly set to ALPHA_ABI_NETBSD, but
> > the second time it gets ALPHA_ABI_UNKNOWN.  This means that the wrong
> > target-dependent info is being used while debugging the core file.
> >
> > This behavior is ... counter-intuitive.  Why is gdbarch_init being called
> > for the core file?  Should't it be sufficient to initialize it based on
> > the program corresponding to the core file?
> 
> There may not necessarily be a program corresponding to the core file:
> gdb --core core.
> 
> > ...or should I make the code that looks for ABI tags in note sections to
> > also look for "NetBSD-CORE" notes, too?
> 
> Sounds right.  I'd check with michael snyder though.

Yeah, bfd has a few holes when it comes to recognizing core files.
If you find one, fill it.  ;-)
Permalink | Reply | 2 comments |
headers
Eli Zaretskii | 25 Apr 2002 20:18
Picon

Re: [RFA] Correct machine name in config/m68k/tm-nbsd.h

> Date: Thu, 25 Apr 2002 12:42:42 +0200
> From: Pierre Muller <muller <at> cerbere.u-strasbg.fr>
> >
> >FYI, the guidelines for such decisions are in standards.texi (IIRC).
> Sorry, but I went trough (quickly)
> but didn't find anything about
> years for copyrights.

Sorry, my memory betrayed me: the guidelines I had in mind are in
maintain.texi, not in standards.texi.  (You can download maintain.texi
from the GNU FTP site, if you don't have it.)  Look for a node
"Copyright Notices" in that manual.
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 25 Apr 2002 20:50

Re: gdbarch_init called for core files, too?

On Thu, Apr 25, 2002 at 10:59:21AM -0700, Michael Snyder wrote:

 > Yeah, bfd has a few holes when it comes to recognizing core files.
 > If you find one, fill it.  ;-)

Err, bfd recognizes the core file just fine.  But the core file doesn't
have the same distinctive marks as the executable, although it does have:

Notes at offset 0x000002a8 with length 0x000002f4:
  Owner         Data size       Description
  NetBSD-CORE           0x0000009c      NetBSD procinfo structure
  NetBSD-CORE <at> 1         0x00000100      PT_GETREGS (reg structure)
  NetBSD-CORE <at> 1         0x00000108      PT_GETFPREGS (fpreg structure)

Now, the the annoying things is that the BFD section that these notes
are located in is called:

 10 note10        000002f4  0000000000000000  0000000000000000  000002a8  2**0
                  CONTENTS, READONLY

...and the name changes based on how many sections preceed it.  Sure, I
could use strncmp(), but it's still icky :-)

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 25 Apr 2002 20:56

Re: gdbarch_init called for core files, too?

On Thu, Apr 25, 2002 at 10:35:04AM -0700, Jason R Thorpe wrote:
> On Thu, Apr 25, 2002 at 01:07:26PM -0400, Andrew Cagney wrote:
> 
>  > There may not necessarily be a program corresponding to the core file: 
>  > gdb --core core.
> 
> Sure, but it doesn't make any sense to do this if there *is* a program
> corresponding to the core file.

I agree with Jason on this.  GNU/Linux code in GDB has started identifying
itself based on .note.ABI-tag sections; once we get an executable, we
don't want to change the architecture again when we load its core file
(which does not have identifying marks).

It seems to me that we should initialize gdbarch when we load a binary,
or once if no binary is loaded; calling the init function with a
corefile is counterintuitive.

> 
>  > > ...or should I make the code that looks for ABI tags in note sections to
>  > > also look for "NetBSD-CORE" notes, too?
>  > 
>  > Sounds right.  I'd check with michael snyder though.
> 
> I looked into this, and I'm not particularly pleased with it as a solution.
> 
> -- 
>         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 25 Apr 2002 20:59

Re: Questions about GDB-MI Interface

On Thu, Apr 25, 2002 at 10:41:07AM -0400, Andrew Cagney wrote:
> >On Thu, 25 Apr 2002, Andrew Cagney wrote:
> >
> >
> >>It was added with much hesitation because there was real concern that 
> >>once a vaguely looking console mechanism was added, people would try to 
> >>use it instead of investing the time and resources needed to address the 
> >>problem of implementing a real console interface.
> >
> >
> >What was envisioned as a solution for the problem at hand, namely, that 
> >any decent front-end to GDB must allow the user to type CLI commands?
> 
> My best answer is that it was envisioned to be fixed in 2.0.  Several 
> alternatives were suggested but no decision was made.  Apple has has 
> since, kind of, made the decision by comming up with a working solution.
> 
> Of the alternatives I remember:
> 
> 	-	properly wrap the CLI up in an
> 		MI command (what apple did).
> 
> 		Has problems with query() where
> 		the CLI wants to prompt back
> 		to the user.
> 
> 		(apple's solution)
> 
> 	-	separate out the CLI from GDB
> 		and have it as a separate MI
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Snyder | 25 Apr 2002 20:47
Picon
Favicon

Re: gdbarch_init called for core files, too?

Jason R Thorpe wrote:
> 
> On Thu, Apr 25, 2002 at 10:59:21AM -0700, Michael Snyder wrote:
> 
>  > Yeah, bfd has a few holes when it comes to recognizing core files.
>  > If you find one, fill it.  ;-)
> 
> Err, bfd recognizes the core file just fine.  But the core file doesn't
> have the same distinctive marks as the executable, although it does have:
> 
> Notes at offset 0x000002a8 with length 0x000002f4:
>   Owner         Data size       Description
>   NetBSD-CORE           0x0000009c      NetBSD procinfo structure
>   NetBSD-CORE <at> 1         0x00000100      PT_GETREGS (reg structure)
>   NetBSD-CORE <at> 1         0x00000108      PT_GETFPREGS (fpreg structure)
> 
> Now, the the annoying things is that the BFD section that these notes
> are located in is called:
> 
>  10 note10        000002f4  0000000000000000  0000000000000000  000002a8  2**0
>                   CONTENTS, READONLY
> 
> ...and the name changes based on how many sections preceed it.  Sure, I
> could use strncmp(), but it's still icky :-)

That's somewhat standard for bfd and corefiles.  The note sections are
numbered consecutively, and sometimes one note section is broken up 
into several pseudo-sections with special, meaningful names.  The 
sections with actual memory / data in them are also numbered
consecutively.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Ingham | 25 Apr 2002 21:23
Picon
Favicon

Re: Questions about GDB-MI Interface`

I think we are in agreement, but just to restate:

First off, we should make a distinction between running a CLI command while
using the MI interpreter, and using the CLI's *_command implementation of
some functionality to get the job done because there is no MI equivalent.

The goal originally was that the MI would not use any of the CLI's *_command
C functions.  If it really needed to, that probably meant that the *_command
function in question should be split off into a CLI bit, which just handled
the arguments, and a function which did all the interesting bits, and then
the mi command for the same functionality would do its argument parsing, and
then run the implementation function.

This is a good goal, it makes the gdb interfaces much cleaner, and not
dependent on the nature of gdb's CLI.  The hack in the MI is that it's
"unknown command" function passes the command to the CLI's execute_command.
This is not a very good way to run CLI commands, as you have found, and not
a good way to structure gdb either.  So I don't think there are any good
arguments for keeping it around, except the we haven't finished the MI
one...

I think that there are also lots of folks who are very used to the gdb CLI,
so supporting routing CLI commands through the MI interpreter is also
important.  But  this function is NOT fulfilled by using the CLI as the
backstop for MI commands....

> 
> I think Apple's solution is a good start for solving this CLI-in-MI
> problem.  Allowing frontends to switch interfaces dynamically will ensure
> that we can provide consistent CLI-style responses to users if needed to.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane