| Re: [hatari-devel] section, symbols and autocompletion |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 01/02/2018 06:55 PM, Nicolas Pomarède wrote:
Le 01/01/2018 à 01:18, Eero Tamminen a écrit :
Hi and happy new year to all !
Happy (late) new year!
[...]>>> Maybe symbols autocompletion should not limit to a specific
type of
section ? (or add an option to do this)
Eero, what do you think ?
There were few reasons for limiting. Large C-programs can easily
have thousands of symbols. Limiting the auto-completion makes
things easier,
The potential amount of symbols was the main reason:
----------------------------------------
> b _<TAB>
Display all 2301 possibilities? (y or n)
----------------------------------------
With the type matching separation I also don't need to show warnings
for the symbol name conflicts between symbols of different types when
symbols are loaded.
especially if there are TEXT & DATA symbols with
same names. It avoid user accidentally using wrong symbol, by
not providing choices that are in most cases bogus.
Is that possible to have the same name both in text and data section ?
At least in asm I don't think so and in C you can't give the same name
to a variable and a function (or maybe if using different source files
and handling this at linking time ?)
Different compilation units can contain duplicate symbols.
Most linkers will give errors only for missing symbols.
Most of the duplicate symbols are naturally local, but
there could be also duplicate global symbol names in symbol
table, if their names get truncated.
(Newer linkers support longer symbol names than what the old
DRI symbol table format supports.)
Also, if one reason for limiting completion to text or data section is
the time it takes to search for the symbol or the memory needed to
handle the symbols lists in the debugger, I think that given today's PC
with CPU and RAM we can remove this limitation.
Performance is no concern for TAB completion (only for profiling,
where address search is done for every emulated instruction).
Note that only auto-completion is limited, the actual disassembly
will still show all symbol types, that are on disassembled addresses
(instead of between them). And you can still type the symbol name
in full.
What others think?
* Should this be changed
* Or should there be an option for it
?
For people coming from real ST and using MonST or adebog, I think a
better default would be to auto complete everything.
It all depends on how people use Hatari to code ; based on the most
recent programs relased for ST, it would seem that people mostly code
demos, then a few games were released (which often require asm for
proper performance) and not that much program using C for example.
But maybe I'm biased :)
Santa brought config option and debugger command for toggling this.
(For completeness sake, attached is alternative change for removing
the distinction in TAB completion completely.)
There's also config file option for the "symbols resident" option
that I added earlier.
- Eero
PS. I also moved exception mask setting from Log section in config file
to Debugger section where it belongs to.
diff -r 81bff329265a src/debug/debugcpu.c
--- a/src/debug/debugcpu.c Wed Jan 03 22:29:28 2018 +0100
+++ b/src/debug/debugcpu.c Sat Jan 06 22:40:28 2018 +0200
@@ -689,7 +689,7 @@
{
{ NULL, NULL, "CPU commands", NULL, NULL, NULL, false },
/* NULL as match function will complete file names */
- { DebugCpu_BreakAddr, Symbols_MatchCpuCodeAddress,
+ { DebugCpu_BreakAddr, Symbols_MatchCpuAddress,
"address", "a",
"set CPU PC address breakpoints",
BreakAddr_Description,
@@ -699,7 +699,7 @@
"set/remove/list conditional CPU breakpoints",
BreakCond_Description,
true },
- { DebugCpu_DisAsm, Symbols_MatchCpuCodeAddress,
+ { DebugCpu_DisAsm, Symbols_MatchCpuAddress,
"disasm", "d",
"disassemble from PC, or given address",
"[<start address>[-<end address>]]\n"
@@ -718,7 +718,7 @@
"\tSet CPU register to value or dumps all register if no parameter\n"
"\thas been specified.",
true },
- { DebugCpu_MemDump, Symbols_MatchCpuDataAddress,
+ { DebugCpu_MemDump, Symbols_MatchCpuAddress,
"memdump", "m",
"dump memory",
"[<start address>[-<end address>]]\n"
diff -r 81bff329265a src/debug/debugdsp.c
--- a/src/debug/debugdsp.c Wed Jan 03 22:29:28 2018 +0100
+++ b/src/debug/debugdsp.c Sat Jan 06 22:40:28 2018 +0200
@@ -539,7 +539,7 @@
static const dbgcommand_t dspcommands[] =
{
{ NULL, NULL, "DSP commands", NULL, NULL, NULL, false },
- { DebugDsp_BreakAddr, Symbols_MatchDspCodeAddress,
+ { DebugDsp_BreakAddr, Symbols_MatchDspAddress,
"dspaddress", "da",
"set DSP PC address breakpoints",
BreakAddr_Description,
@@ -550,13 +550,13 @@
"set/remove/list conditional DSP breakpoints",
BreakCond_Description,
true },
- { DebugDsp_DisAsm, Symbols_MatchDspCodeAddress,
+ { DebugDsp_DisAsm, Symbols_MatchDspAddress,
"dspdisasm", "dd",
"disassemble DSP code",
"[<start address>[-<end address>]]\n"
"\tDisassemble from DSP-PC, otherwise at given address.",
false },
- { DebugDsp_MemDump, Symbols_MatchDspDataAddress,
+ { DebugDsp_MemDump, Symbols_MatchDspAddress,
"dspmemdump", "dm",
"dump DSP memory",
"[<x|y|p> <start address>[-<end address>]]\n"
diff -r 81bff329265a src/debug/symbols.c
--- a/src/debug/symbols.c Wed Jan 03 22:29:28 2018 +0100
+++ b/src/debug/symbols.c Sat Jan 06 22:40:28 2018 +0200
@@ -1112,7 +1112,7 @@
* STATE = 0 -> different text from previous one.
* Return (copy of) next name or NULL if no matches.
*/
-static char* Symbols_MatchByName(symbol_list_t* list, symtype_t symtype, const char *text, int state)
+static char* Symbols_MatchByName(symbol_list_t* list, const char *text, int state)
{
static int i, len;
const symbol_t *entry;
@@ -1130,8 +1130,7 @@
/* next match */
entry = list->names;
while (i < list->namecount) {
- if ((entry[i].type & symtype) &&
- strncmp(entry[i].name, text, len) == 0) {
+ if (strncmp(entry[i].name, text, len) == 0) {
return strdup(entry[i++].name);
} else {
i++;
@@ -1147,15 +1146,7 @@
*/
char* Symbols_MatchCpuAddress(const char *text, int state)
{
- return Symbols_MatchByName(CpuSymbolsList, SYMTYPE_ALL, text, state);
-}
-char* Symbols_MatchCpuCodeAddress(const char *text, int state)
-{
- return Symbols_MatchByName(CpuSymbolsList, SYMTYPE_TEXT, text, state);
-}
-char* Symbols_MatchCpuDataAddress(const char *text, int state)
-{
- return Symbols_MatchByName(CpuSymbolsList, SYMTYPE_DATA|SYMTYPE_BSS, text, state);
+ return Symbols_MatchByName(CpuSymbolsList, text, state);
}
/**
@@ -1165,15 +1156,7 @@
*/
char* Symbols_MatchDspAddress(const char *text, int state)
{
- return Symbols_MatchByName(DspSymbolsList, SYMTYPE_ALL, text, state);
-}
-char* Symbols_MatchDspCodeAddress(const char *text, int state)
-{
- return Symbols_MatchByName(DspSymbolsList, SYMTYPE_TEXT, text, state);
-}
-char* Symbols_MatchDspDataAddress(const char *text, int state)
-{
- return Symbols_MatchByName(DspSymbolsList, SYMTYPE_DATA|SYMTYPE_BSS, text, state);
+ return Symbols_MatchByName(DspSymbolsList, text, state);
}
diff -r 81bff329265a src/debug/symbols.h
--- a/src/debug/symbols.h Wed Jan 03 22:29:28 2018 +0100
+++ b/src/debug/symbols.h Sat Jan 06 22:40:28 2018 +0200
@@ -20,12 +20,8 @@
/* readline completion support functions for CPU */
extern char* Symbols_MatchCpuAddress(const char *text, int state);
-extern char* Symbols_MatchCpuCodeAddress(const char *text, int state);
-extern char* Symbols_MatchCpuDataAddress(const char *text, int state);
/* readline completion support functions for DSP */
extern char* Symbols_MatchDspAddress(const char *text, int state);
-extern char* Symbols_MatchDspCodeAddress(const char *text, int state);
-extern char* Symbols_MatchDspDataAddress(const char *text, int state);
/* symbol name -> address search */
extern bool Symbols_GetCpuAddress(symtype_t symtype, const char *name, Uint32 *addr);
extern bool Symbols_GetDspAddress(symtype_t symtype, const char *name, Uint32 *addr);