This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/355: Any remote config (like gdbserver, or even monitor, I think...) that
- From: anonymous at sources dot redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 13 Feb 2002 06:28:32 -0000
- Subject: gdb/355: Any remote config (like gdbserver, or even monitor, I think...) that
>Number: 355
>Category: gdb
>Synopsis: Any remote config (like gdbserver, or even monitor, I think...) that
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: doc-bug
>Submitter-Id: net
>Arrival-Date: Tue Feb 12 22:38:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
(The doco should be moved to the internals manual.)
Try:
>
> (gdb) maint print architecture [ <savefile> ]
>
> and look at sizeof.exp.
>
> The lack of output comes, at least in part, because it isn't possible to
> print the macros/values safely.
>
> Andrew
Thanks. Shouldn't http://sources.redhat.com/gdb/papers/multi-arch/howto.ht
ml be updated to show this. At present it says:
Add:
#ifndef GDB_MULTI_ARCH
#define GDB_MULTI_ARCH 1
#endif
to the top of your tm-XXX.h file. Rebuild and then run GDB vis:
gdb/gdb
(gdb)
(gdb) set archdebug 1
(gdb) file x-y-z
....
If all goes well, gdb will report the current value of all the
architecture dependent macro's. ...
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
overrides gdb_target_cmd/gdb_file_cmd loses because of the static mi version
in mi-support.exp. This leads to almost a day's worth of timeouts. I've
tried to cobble together a gdbserver version of mi_gdb_file_cmd and an
mi-aware mi_gdb_target_cmd; I can't do it.
multi-arch howto update
From: ac131313@redhat.com
Reply-To: ac131313@redhat.com
X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31)
X-GNATS-Notify:
overrides gdb_target_cmd/gdb_file_cmd loses because of the static mi version
in mi-support.exp. This leads to almost a day's worth of timeouts. I've
tried to cobble together a gdbserver version of mi_gdb_file_cmd and an
mi-aware mi_gdb_target_cmd; I can't do it.
multi-arch howto update