Original date:2022-02-27 02:43:43 Edited by: abuaf Subject: Re: BREAKing into Euphoria

ghaberek said...

Yes you're right. Sorry I missed that. But even without assembly code, poking directly at random memory addresses is bad. The correct way to do this is either in via the backend, as I've implemented above, or via the external debugger API, which I'll work on adapting -Greg

"I've (you've) implemented"??? Did you already implement this, and has it made it to github since that would save me time? If you implement it in the backend, then there's no need to add a debug API for it. I find this backend method useful for libraries; often you don't want to pop out to the debugger in the library (which has been tested to work) - the problem is with the user app (same for type checks). What you want is to pop up the debugger in the user's code ("with trace" section), and keep the library / type check "without trace". This reflects an elegance of euphoria; that the user has control of the scope of debuggability, only now it can be queued in "without trace" sections.

I've been having some thoughts about the debugger API;

  • Does it extend euphoria's internal debugger functionality or does the API replace that functionality? Obviously very unattractive and wasteful to recreate the existing debugger's functionality.
  • My pet annoyance is the debugger's ignorance of string sequences and thumping them out as interspersed numbers. Naturally we don't want to explicity run-time mark sequences as 'strings'. But we could modify the interpreter to assign some pointer part of the string to a string memory address range, and have an API to query the string-edness of a sequence.
  • Irrespective of above implicit string marking, a 's' command to print out a sequence as a string ???
  • Quick hack; a 'string' type check, that not only checks that all sequence elements are integers [0..255] , but makes a simplified CRC of the sequence and stores that for later so the debugger can match against it and print appropriately. The aim here is to fingerprint strings on assignment. Maybe there's a faster backend method to finger print sequences based on their internal pointers.
  • The string printing issue is part of a bigger issue on sequence printing in general. In the end only the eu app can pretty print a complex sequence according to appropriate user preference. Ie you dont want a detailed page long full dump of a complex sequence. So i would suggest a eu callback (in "without trace" code to prevent recursion) that would take a sequence as input, and return a string for the debugger to print. This would apply to the new debugger 's' command, so if the user really wants a full dump, use the usual '?' command.
Not Categorized, Please Help


Quick Links

User menu

Not signed in.

Misc Menu