gnupic: Thread: Re: [gnupic] Re: debugging gpasm

> On Sat, 17 Mar 2007 18:15:25 -0500
> David ####@####.#### wrote:
>> ...
>> I run it like this:
>>   $ gdb gpasm
>>   (gdb) run gpasm file.c
> Sorry, I meant to say this:
>   (gdb) run gpasm main.asm

But I think you really meant to say

(gdb) run main.asm

Scott

:)

On 3/18/07, Scott Dattalo ####@####.#### wrote:
>
> > On Sat, 17 Mar 2007 18:15:25 -0500
> > David ####@####.#### wrote:
> >> ...
> >> I run it like this:
> >>   $ gdb gpasm
> >>   (gdb) run gpasm file.c
> > Sorry, I meant to say this:
> >   (gdb) run gpasm main.asm
>
> But I think you really meant to say
>
> (gdb) run main.asm
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>

On Sat, 17 Mar 2007 19:17:29 -0800 (PST)
"Scott Dattalo" ####@####.#### wrote:

> > On Sat, 17 Mar 2007 18:15:25 -0500
> > David ####@####.#### wrote:
> >> ...
> >> I run it like this:
> >>   $ gdb gpasm
> >>   (gdb) run gpasm file.c
> > Sorry, I meant to say this:
> >   (gdb) run gpasm main.asm
> 
> But I think you really meant to say
> 
> (gdb) run main.asm
=) yes, I did...  Sorry.  I should double-check things like that.
Do you get the same error?  Am I forgetting something about gdb
(likely) or is there something else with gputils?

I'm trying to patch up some of the bugs with text substitution from the
bug tracker, but I'm not getting very far without gdb.  BTW, I'm
currently looking into bug #1250441 with the #v syntax.  I added some
comments about some interesting developments.

David

On Sun, 18 Mar 2007 08:23:52 -0500
David ####@####.#### wrote:

> On Sat, 17 Mar 2007 19:17:29 -0800 (PST)
> "Scott Dattalo" ####@####.#### wrote:
> 
> Do you get the same error?  Am I forgetting something about gdb
> (likely) or is there something else with gputils?
Please disregard.  I seemed to have messed up the installation somehow
when I added debug information.  It works now.

David

On Sun, Mar 18, 2007 at 08:23:52AM -0500, David wrote:
> On Sat, 17 Mar 2007 19:17:29 -0800 (PST)
> "Scott Dattalo" ####@####.#### wrote:
> 
> > > On Sat, 17 Mar 2007 18:15:25 -0500
> > > David ####@####.#### wrote:
> > >> ...
> > >> I run it like this:
> > >>   $ gdb gpasm
> > >>   (gdb) run gpasm file.c
> > > Sorry, I meant to say this:
> > >   (gdb) run gpasm main.asm
> > 
> > But I think you really meant to say
> > 
> > (gdb) run main.asm
> =) yes, I did...  Sorry.  I should double-check things like that.
> Do you get the same error?  Am I forgetting something about gdb
> (likely) or is there something else with gputils?
> 
> I'm trying to patch up some of the bugs with text substitution from the
> bug tracker, but I'm not getting very far without gdb.  BTW, I'm
> currently looking into bug #1250441 with the #v syntax.  I added some
> comments about some interesting developments.

As soon as I saw the #v syntax, memories came flooding back. It's definitely
broken. 

The signature application I always wanted to use that utilized this syntax
is Wouter von Ooijen's WLoader bootloader. You can find it here:

http://www.voti.nl/wloader

It uses the syntax extensively and none of it works. Please use it as a test
case. That bootloader is still valuable.

BAJ

On Sun, 18 Mar 2007 10:58:45 -0400
Byron A Jeff ####@####.#### wrote:

> On Sun, Mar 18, 2007 at 08:23:52AM -0500, David wrote:
> > I'm trying to patch up some of the bugs with text substitution from
> > the bug tracker, but I'm not getting very far without gdb.  BTW, I'm
> > currently looking into bug #1250441 with the #v syntax.  I added
> > some comments about some interesting developments.
> 
> As soon as I saw the #v syntax, memories came flooding back. It's
> definitely broken. 
Yes, I know.  Traumatic, isn't it?  I added some more comments to the
effect that the problem is much more complicated than I expected
(but at least I know what it is now).  I was hoping to add some small
features to find my way around gputils, but it turned out to need sort
of an overhaul.  I may need to work on something else until I get a
better feel for the architecture.

On that note, I've done some thinking about how the different text
substitutions interact.  The categories I can think of are assembler
variables, #defines, #v substitutions, and macros. gpasm enforces a
sort of hierarchy to them, which simplifies some things, but I think
each of them can be nested in each of the others. MPASM makes 8 passes
and then gives up on any remaining relocations, I think without any
concept of precedence.  I don't like the arbitrary restriction since
any code could happen to just barely need 9 passes, and then it would
be difficult to work around the limitation.  I think for gpasm to fix
all of the related bugs, it will need to do away with the hierarchy,
but we should be able to detect infinite recursion so that we can
provide arbitrary levels of nesting.

Does anyone disagree or have any comments?

David

On Sun, Mar 18, 2007 at 10:34:06PM -0500, David wrote:
> On Sun, 18 Mar 2007 10:58:45 -0400
> Byron A Jeff ####@####.#### wrote:
> 
> > On Sun, Mar 18, 2007 at 08:23:52AM -0500, David wrote:
> > > I'm trying to patch up some of the bugs with text substitution from
> > > the bug tracker, but I'm not getting very far without gdb.  BTW, I'm
> > > currently looking into bug #1250441 with the #v syntax.  I added
> > > some comments about some interesting developments.
> > 
> > As soon as I saw the #v syntax, memories came flooding back. It's
> > definitely broken. 
> Yes, I know.  Traumatic, isn't it?  I added some more comments to the
> effect that the problem is much more complicated than I expected
> (but at least I know what it is now).  I was hoping to add some small
> features to find my way around gputils, but it turned out to need sort
> of an overhaul.  I may need to work on something else until I get a
> better feel for the architecture.
> 
> On that note, I've done some thinking about how the different text
> substitutions interact.  The categories I can think of are assembler
> variables, #defines, #v substitutions, and macros. gpasm enforces a
> sort of hierarchy to them, which simplifies some things, but I think
> each of them can be nested in each of the others. MPASM makes 8 passes
> and then gives up on any remaining relocations, I think without any
> concept of precedence.  I don't like the arbitrary restriction since
> any code could happen to just barely need 9 passes, and then it would
> be difficult to work around the limitation.  I think for gpasm to fix
> all of the related bugs, it will need to do away with the hierarchy,
> but we should be able to detect infinite recursion so that we can
> provide arbitrary levels of nesting.
> 
> Does anyone disagree or have any comments?

My instant gut thought is first think through what the common usage would be
and figure out if the current infrastructure can support it. A complete
overhaul would be painful I think.

BAJ

----- Original Message ----- 
From: "Byron A Jeff" ####@####.####
To: ####@####.####
Sent: Monday, March 19, 2007 6:13 AM
Subject: Re: [gnupic] Re: debugging gpasm


> My instant gut thought is first think through what the common usage would 
> be
> and figure out if the current infrastructure can support it. A complete
> overhaul would be painful I think.
You are right, "overhaul" may be a bit exaggerated.  I thought from looking 
at the problem description that it would be a superficial change, and it 
turned out to be a little more involved.  There may be some pretty 
fundamental changes involved, but I'll still have to figure some more of the 
architecture out before I can get to it.

BTW, I've found gdb to be pretty useful for making some sense of unfamiliar 
code.  I'm getting sort of off-topic here, but are there any other tricks 
that anyone finds particularly helpful?  For instance, I've played with 
cscope a little bit.  I've heard using an IDE can help, too, but I've always 
just programmed in vi.  A friend told me that reading through source code 
doesn't help much and you just have to dive in and start changing stuff to 
see how it changes the program's operation.

I also found a book called "Code Reading" by Diomidis Spinellis that claims 
to help with that task, but from reviews and the sample chapter, I gather 
that it's just basic programming tips and not worth the read.  Sean Egan 
also wrote a book about his work on Gaim that got much better reviews and 
supposedly talks about general techniques.  Can books help that much with 
learning to work on other people's code?

I ask all this because I've been trying to get involved in several projects 
in the past and always found it too overwhelming.  I never wanted to bother 
people with the details in the past, but I figured this is as good a place 
to ask as any.

David 

On Wednesday 21 March 2007 14:59, David Barnett wrote:
> ----- Original Message -----
> From: "Byron A Jeff" ####@####.####
> To: ####@####.####
> Sent: Monday, March 19, 2007 6:13 AM
> Subject: Re: [gnupic] Re: debugging gpasm
>
> > My instant gut thought is first think through what the common usage would
> > be
> > and figure out if the current infrastructure can support it. A complete
> > overhaul would be painful I think.
>
> You are right, "overhaul" may be a bit exaggerated.  I thought from looking
> at the problem description that it would be a superficial change, and it
> turned out to be a little more involved.  There may be some pretty
> fundamental changes involved, but I'll still have to figure some more of
> the architecture out before I can get to it.
>
> BTW, I've found gdb to be pretty useful for making some sense of unfamiliar
> code.  I'm getting sort of off-topic here, but are there any other tricks
> that anyone finds particularly helpful?  For instance, I've played with
> cscope a little bit.  I've heard using an IDE can help, too, but I've
> always just programmed in vi.  A friend told me that reading through source
> code doesn't help much and you just have to dive in and start changing
> stuff to see how it changes the program's operation.
>
> I also found a book called "Code Reading" by Diomidis Spinellis that claims
> to help with that task, but from reviews and the sample chapter, I gather
> that it's just basic programming tips and not worth the read.  Sean Egan
> also wrote a book about his work on Gaim that got much better reviews and
> supposedly talks about general techniques.  Can books help that much with
> learning to work on other people's code?
>
> I ask all this because I've been trying to get involved in several projects
> in the past and always found it too overwhelming.  I never wanted to bother
> people with the details in the past, but I figured this is as good a place
> to ask as any.
>
> David

Two tools you'll find invaluable:

  * RedHat's Source Navigator (http://sourcenav.sourceforge.net/)
  * GNU's ID Utils (http://www.gnu.org/software/idutils/)

ID Utils is especially useful when used with emacs.

Make a wiki, documenting what you discover and understand about the code (I 
suggest "trac", as it integrates version control, wiki, ticketing, ...).
Possible, when not already there, add documentation to the code, using a tool 
like doxygen (it can be integrated with trac too).

Understanding code written by others is hard. Use your brain.

Ciao,
Marco

-- 
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi David,

> I'm getting sort of off-topic here, but are there any other tricks
> that anyone finds particularly helpful?  For instance, I've played
> with cscope a little bit.  I've heard using an IDE can help, too, but
> I've always just programmed in vi.

I too have used cscope.  If you use vi, I assume you are familiar with
tags, e.g. Ctrl-] and Ctrl-T.

    http://vimdoc.sourceforge.net/htmldoc/usr_29.html
    http://ctags.sourceforge.net/

Also, GNU's ID Utils can be useful for fast searches of a source
hierarchy.

    http://www.gnu.org/software/idutils/

Finally, GNU Global can be useful too.  It's a bit like the others but
can generate a HTML tree of the source for hypertext browsing.

    http://www.gnu.org/software/global/
    http://www.tamacom.com/tour/kernel/linux/

Cheers,


Ralph.