Re: freebsd-hackers Digest, Vol 305, Issue 6
On Sat, Jan 31, 2009 at 1:00 PM, wrote: > > Message: 4 > Date: Fri, 30 Jan 2009 09:41:58 -0800 > From: "Matthew Fleming" > Subject: Dynamic ddb commands > To: > Message-ID: <127318.13748.101.ca...@amaretto> > Content-Type: text/plain; charset="iso-8859-1" > > I'm working on BSD 6.x and of course the set of ddb commands is static > to whatever is in the kernel at compile. I see that BSD 7.1 has dynamic > commands using sysinits and sysuninit's to call a new > db_[un]register_cmd. > > I see this, though, only after I have spent a day or so adding a > linker_file_[un]register_ddb() that works similarly to how sysinits are > merged for the boot-time modules (malloc and copy pointers). It seems > to me that this solution (have the linker look for db_set and db_cmd_set > and, if there are any entries, malloc and save pointers to commands) is > more efficient in terms of space than adding a LIST to the command > structure and then forcing sysinits to run. This is what I proposed at first, you can find a patch doing just that following that thread: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg65165.html But Sam and John suggested to use the sysinit facility instead. I am convinced they are right: - Sysinits are a proven system, this is the least friction path. Also, by adding functions to the linker you still have the (small but existing) risk of adding bugs to that system. - This require adding new sections. Now, on regular x86 machines that doesn't seem too much of a problem. I am however currently working on a port of FreeBSD to some ARM cortex-based board. When debugging using JTAG, the smaller amount of sections whose location in physical memory I have to care about, the simpler for me and those doing the same kind of work. - You are not "forcing" sysinits to run: they are run no matter what when loading a module. - You can still debug sysinits when inserting modules, as the core of the debugger is already running and the list has been loaded in memory. The modules command itself will of course not be available, but the base commands will still be here. Cheers, Guillaume ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[PATCH] Extending the ddb command set
Hello hackers,
I sent a patch some time ago, allowing modules to extend the ddb
command set. I just realized the link I provided then was in French so
that might have discouraged people from going any further. I have
therefore posted it here. Also, since I would like this patch to be
committed at some point, I have written a man page that I also
enclosed. Comments are welcome.
The man page:
.Dd August 27, 2008
.Dt DB_COMMAND 9
.Os
.Sh NAME
.Nm DB_COMMAND ,
.Nm DB_SHOW_COMMAND ,
.Nm DB_SHOW_ALL_COMMAND
.Nd Extends the ddb command set.
.Sh SYNOPSIS
.In ddb/ddb.h
.Fo DB_COMMAND
.Fa command_name
.Fa command_function
.Fc
.Fn DB_SHOW_COMMAND "command_name" "command_function"
.Fn DB_SHOW_ALL_COMMAND "command_name" "command_function"
.Sh DESCRIPTION
.Pp
The
.Fn DB_COMMAND
macro adds
.Fa command_name
to the list of top-level commands. Invoking
.Fa command_name
from ddb will call
.Fa command_function .
.Pp
The
.Fn DB_SHOW_COMMAND
and
.Fn DB_SHOW_ALL_COMMAND
are roughly equivalent to
.Fn DB_COMMAND
but in these cases,
.Fa command_name
is a sub-command of the ddb
.Sy show
command and
.Sy show all
command, respectively.
.Pp
The general command syntax:
.Cm command Ns Op Li \&/ Ns Ar modifier
.Ar address Ns Op Li , Ns Ar count ,
translates into the following parameters for
.Fa command_function :
.Bl -tag
.It Fa addr
The address passed to the command as an argument.
.It Fa have_addr
A boolean value that is true if the addr field is valid.
.It Fa count
The number of quad words starting at offset
.Fa addr
that the command must process.
.It Fa modif
A pointer to the string of modifiers. That is, a series of symbols
used to pass some options to the command. For example, the
.Sy examine
command will display words in decimal form if it is passed the modifier "d".
.El
.Sh EXAMPLE
In your module, the command is declared as:
.Pp
.Bd -literal
DB_COMMAND(mycmd, my_cmd_func)
{
if (have_addr)
db_printf("Calling my command with address %p\\n", addr);
}
.Ed
.Pp
Then, when in ddb:
.Pp
.Bd -literal
.Bf Sy
db> mycmd 0x1000
Calling my command with address 0x1000
db>
.Ef
.Ed
.Sh "SEE ALSO"
.Xr ddb 4
.Sh AUTHOR
This manual page was written by
.An Guillaume Ballet Aq [EMAIL PROTECTED] .
And the patch:
--- ./ddb/db_command.c.orig 2008-08-19 00:56:41.0 +0200
+++ ./ddb/db_command.c 2008-08-24 20:59:41.0 +0200
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -76,78 +77,68 @@
static db_cmdfcn_t db_watchdog;
/*
+ * Array containing all command 'tables'. See ddb.h.
+ */
+static struct command_table db_command_tables[DB_COMMAND_TABLES_SIZE] = {
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_DEFAULT]),
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW]),
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW_ALL])
+};
+
+/*
* 'show' commands
*/
static struct command db_show_all_cmds[] = {
- { "procs", db_ps, 0, 0 },
- { (char *)0 }
-};
-
-static struct command_table db_show_all_table = {
- db_show_all_cmds
+ { { NULL }, "procs",db_ps, 0, 0 }
};
static struct command db_show_cmds[] = {
- { "all",0, 0, &db_show_all_table },
- { "registers", db_show_regs, 0, 0 },
- { "breaks", db_listbreak_cmd, 0, 0 },
- { "threads",db_show_threads,0, 0 },
- { (char *)0, }
+ { { NULL }, "all", 0, 0,
&db_command_tables[DB_COMMAND_TABLES_SHOW_ALL] },
+ { { NULL }, "registers",db_show_regs, 0, 0 },
+ { { NULL }, "breaks", db_listbreak_cmd, 0, 0 },
+ { { NULL }, "threads", db_show_threads,0, 0 }
};
-static struct command_table db_show_table = {
- db_show_cmds,
- SET_BEGIN(db_show_cmd_set),
- SET_LIMIT(db_show_cmd_set)
-};
-
static struct command db_commands[] = {
- { "print", db_print_cmd, 0, 0 },
- { "p", db_print_cmd, 0, 0 },
- { "examine",db_examine_cmd, CS_SET_DOT, 0 },
- { "x", db_examine_cmd, CS_SET_DOT, 0 },
- { "search", db_search_cmd, CS_OWN|CS_SET_DOT, 0 },
- { "set",db_set_cmd, CS_OWN, 0 },
- { "write", db_write_cmd, CS_MORE|CS_SET_DOT, 0 },
- { "w", db_write_cmd, CS_MORE|CS_SET_DOT, 0 },
- { "delete", db_delete_cmd, 0, 0 },
- { "d", db_delete_cmd,
Re: Extending the ddb command set
On Mon, Aug 18, 2008 at 2:02 PM, John Baldwin <[EMAIL PROTECTED]> wrote: > (snip) > A simpler approach is probably to make DB_COMMAND() use a SYSINIT to register > new functions instead of teaching DDB about that linker set. You just need > to write a shared "register_command()" function (and a deregister for > SYSUNINIT for module unload) that the SYSINIT uses. This also probably > requires changing the structure of the DDB tables, though you might be able > to make it simpler now. You could probably just make the tables be sorted > linked lists now instead of arrays. This would also remove the whole "aux > table" hack. > Following Sam and John's advice, I have rewritten the patch so as to use SYS(UN)INIT. It uses a linked list instead of an array to store commands. As the patch is more than 400 lines long, it is available for reviewing at: http://dl.free.fr/jQQQkB72h0 I used 7.0 ; 6.2 requires a bit more work. Many thanks to Sam, John and Kostik for their suggestions. Feedback is still welcome :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Extending the ddb command set
On Sun, Aug 17, 2008 at 6:23 PM, Sam Leffler <[EMAIL PROTECTED]> wrote:
(snip)
> Last I looked at this I was convinced it could be done using SYSINIT's and
> the existing mechanisms for adding ddb cmds. I don't think you need to
> modify the linker or ddb. Not sure if you looked sys/module.h and/or
> sys/kernel.h?
I have indeed looked at these files. That's actually what brought me
to work on the linker when I realize now that was no necessary.
Looking at them twice didn't hurt, though :)
SYSINIT is a good idea to get some "struct command"s into kernel space
and register them through come command. One can imagine creating a
DB_COMMAND_MODULE macro or something that would do exactly that.
I have however doubts on the registration part: In ddb/db_command.c,
the following table is declared:
static struct command_table db_command_table = {
db_commands,
SET_BEGIN(db_cmd_set),
SET_LIMIT(db_cmd_set)
};
which is the table that is used in db_command_loop. I am not aware of
any other mechanism to add commands to that list. That table is made
up of two parts: The first entry is a list of all the default
commands. The two next entries define the boundaries of a list of
pointers to optional commands. That list could be extended by a
module SYSCTL but:
- The table is declared as static, so at least that part must be
modified, or an accessor must be written. No big deal.
- Memory must be allocated and relevant information must be logged so
as to know what to remove when unloading a module. That is possible,
but I feel it is more risky because memory needs to be allocated and a
set of locks would not hurt in that case.
Parsing the list of modules each time has the advantage that no memory
has to be allocated and there is no concurrency problems when the
debugger is invoked (I think, please let me know if that assumption is
wrong). Also, module unloading is not a problem because once the
module goes, it is not in the list anymore and therefore commands can
not be seen nor accessed anymore.
Of course I could be wrong (or just biased?) so once again let me
know if you think otherwise. Note that I have a simpler patch in
progress that should not alter the linker since it will use
linker_file_foreach.
Either way, thanks for your comments. And sorry about the long message.
Guillaume.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Extending the ddb command set
>> >> It is indeed doable: Here are the diffs for a first attempt at doing >> this. I am not entirely satisfied with it, though, as it does not work >> with DB_SHOW_COMMAND and the likes... Also, I have to declare a lot of >> ddb-related stuff into kern_linker.c and I don't like it. I am >> currently working at improving the whole thing, but in the mean time >> if someone wants to give it a try, comments/rants would be greatly >> appreciated. > > What about module unloading ? > Thanks for replying so quickly :) When a module is unloaded from the system, it is removed from the linker_files list and will therefore not be available anymore when walking through the module list. I have checked on my side and this is indeed what happens. If you saw some problem I didn't, would you please mind to elaborate? Guillaume ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Extending the ddb command set
On Sat, Aug 16, 2008 at 5:15 PM, Sam Leffler <[EMAIL PROTECTED]> wrote:
>
> Guillaume Ballet wrote:
>>
>> Hello hackers,
>>
>> I am currently working on a small project and would like to add a few
>> commands to the set that is available in ddb.
>>
>> I found that very interesting albeit succinct presentation:
>> http://people.freebsd.org/~jhb/papers/bsdcan/2008/slides.odp<http://people.freebsd.org/%7Ejhb/papers/bsdcan/2008/slides.odp>
>>
>> where the author hints that I should use DB_COMMAND, which I did. Yet when
>> invoking ddb, the command does not appear in the help list. I have taken a
>> look at the source code and was expecting set_db_cmd_set to appear in my
>> module's section list when calling objdump -h
>>
>> Is DB_COMMAND only working within the kernel itself, and not modules?
>>
>>
>
> That is correct; you can't add ddb cmds from modules. It should be doable;
> just hasn't been done yet.
>
> Sam
>
It is indeed doable: Here are the diffs for a first attempt at doing
this. I am not entirely satisfied with it, though, as it does not work
with DB_SHOW_COMMAND and the likes... Also, I have to declare a lot of
ddb-related stuff into kern_linker.c and I don't like it. I am
currently working at improving the whole thing, but in the mean time
if someone wants to give it a try, comments/rants would be greatly
appreciated.
Guillaume
--- sys/linker.h.orig2008-08-17 18:45:56.0 +0200
+++ sys/linker.h2008-08-17 18:50:57.0 +0200
@@ -155,6 +155,9 @@
int linker_ddb_search_symbol(caddr_t _value, c_linker_sym_t *_sym,
long *_diffp);
int linker_ddb_symbol_values(c_linker_sym_t _sym, linker_symval_t *_symval);
+struct command;
+int linker_ddb_cmd_search(char *, struct command **);
+int linker_ddb_cmd_list(void);
/* HWPMC helper */
--- kern/kern_linker.c.orig2008-08-17 08:38:51.0 +0200
+++ kern/kern_linker.c2008-08-17 18:47:45.0 +0200
@@ -777,6 +777,9 @@
* that the files list is inconsistant instead.
*/
+#include
+#include
+
int
linker_ddb_lookup(const char *symstr, c_linker_sym_t *sym)
{
@@ -831,6 +834,52 @@
}
return (ENOENT);
}
+
+int linker_ddb_cmd_list()
+{
+linker_file_tlf;
+struct command**start, **stop, **search;
+
+TAILQ_FOREACH(lf, &linker_files, link) {
+if (!linker_file_lookup_set(lf,"db_cmd_set",&start,&stop,NULL)) {
+for (search=start; search < stop; search++) {
+db_printf("%-12s", (*search)->name);
+db_end_line(12);
+}
+}
+}
+
+return 0;
+}
+
+int linker_ddb_cmd_search(char *name, struct command **cmdp)
+{
+linker_file_t lf;
+char *lp, *rp;
+struct command **cmd, **start, **stop;
+int c;
+
+TAILQ_FOREACH(lf, &linker_files, link) {
+if (!linker_file_lookup_set(lf, "db_cmd_set", &start, &stop, NULL)) {
+for (cmd=start; cmd < stop; cmd++) {
+lp= name;
+rp= (*cmd)->name;
+
+while((c = *lp) == *rp) {
+if (c == 0) {
+*cmdp = *cmd;
+return 0;
+}
+
+lp++;
+rp++;
+}
+}
+}
+}
+
+return -1;
+}
#endif
/*
--- ddb/db_command.c.orig2008-08-17 10:26:26.0 +0200
+++ ddb/db_command.c2008-08-17 18:42:22.0 +0200
@@ -253,6 +253,9 @@
if (result == CMD_UNIQUE)
return (CMD_UNIQUE);
}
+if (result == CMD_NONE && linker_ddb_cmd_search(name,cmdp) == 0) {
+result = CMD_UNIQUE;
+}
if (result == CMD_NONE) {
/* check for 'help' */
if (name[0] == 'h' && name[1] == 'e'
@@ -280,6 +283,7 @@
db_printf("%-12s", (*aux_cmdp)->name);
db_end_line(12);
}
+linker_ddb_cmd_list();
}
static void
--- ddb/db_command.h.orig2008-08-17 18:37:34.0 +0200
+++ ddb/db_command.h2008-08-17 18:49:29.0 +0200
@@ -46,4 +46,7 @@
extern db_addr_tdb_next;/* next address to be examined
or written */
+extern int linker_ddb_cmd_search(char*,struct command **);
+extern int linker_ddb_cmd_list(void);
+
#endif /* !_DDB_DB_COMMAND_H_ */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Extending the ddb command set
Hello hackers, I am currently working on a small project and would like to add a few commands to the set that is available in ddb. I found that very interesting albeit succinct presentation: http://people.freebsd.org/~jhb/papers/bsdcan/2008/slides.odp<http://people.freebsd.org/%7Ejhb/papers/bsdcan/2008/slides.odp> where the author hints that I should use DB_COMMAND, which I did. Yet when invoking ddb, the command does not appear in the help list. I have taken a look at the source code and was expecting set_db_cmd_set to appear in my module's section list when calling objdump -h Is DB_COMMAND only working within the kernel itself, and not modules? Guillaume ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bus error - FD or msdos HD mount
hello, since i get no answer in fr.comp.os.bsd, [EMAIL PROTECTED] , and [EMAIL PROTECTED] , i'm trying here now, hoping i'm not too off-charter. i can't mount my floppy disk and my Win98 hard disk. i tape: # mount -t msdos /dev/ad0s1 /hdibm or: # mount -t msdos /dev/fd0.1440 /floppy (or with ad0c, fd0c, ...) and i get "Bus error" and a core file. my bootable Win98 disk (only 1 partition - FAT32, 12.6 Go) is connected in master to the primary IDE. my floppy is a classic 1.44 Mo and i want to read MSDOS formated floppies. of course i have the 2 special files in /dev, and i created the mount directories. i have access to these disks with fsck_msdosfs or disklabel. i followed all the procedure to format and mount a new MSDOS floppy disk but i always have this error. i haven't these problems with my CDROM and my bootable FreeBSD disk. for information i can get the same error when i try to mount one of my FreeBSD partition as a MSDOS partition ( # mount -t msdos /dev/ad3s1g /tmp ). (i'm under FreeBSD 4.7) does somebody know how to resolve this problem? thank you! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
