bugDDD - Bugs: bug #29717, DDD with remake

 
 

bug #29717: DDD with remake

Submitted by:  gnu user <gnuregisterme>
Submitted on:  Thu 29 Apr 2010 07:00:47 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 08 Jul 2014 12:56:17 AM UTC, comment #12:

Hmm, I'm seeing the "remake<<<...3>>>..."-type prompts using plain remake (without ddd) too.

It usually pops up after several recursive calls to remake in my project. I'll try observe if there is any pattern to when it appears and keep you posted on this.

I've also gotten in touch with gnu-people about getting commit access to this project, late last week, no response as yet, but hopefully in the coming days.

I'll try follow up on your suggestions to commit, make tarball, etc, incrementally over time.

I've got limited time to absorb the ways of the GNU universe, but I'll try nibble away at it over time :)

Gurce Isikyildiz <gurce>
Wed 02 Jul 2014 12:48:00 PM UTC, comment #11:

Not sure why you are seeing ..., but I'm guessing it's a DDD artifact, not a GNU remake one. To verify, try the same thing outside of DDD, that is just using remake.

As for --, that's what you get when you step, <- is yes, I think for after you finish remaking the target. I'll track it down in more detail (use the source) and document it in the guide and probably in the remake wiki as well.

At this point since you've been doing this much work on this, consider forking the code and putting it somewhere for others to have easily accessible. And/or create a tarball for this. I could probably add the tarball under the sourceforge remake project page if not also the ddd one. (I haven't checked the ddd one in a while). But unless you provide some version-control way of having others improve upon this, the tarball will be come stale quite soon.

Rocky Bernstein <rocky>
Project Member
Wed 02 Jul 2014 12:23:23 PM UTC, comment #10:

Ah finally, I've got the "up" and "down" commands working.

It turns out that it was failing due to the pos-buffer information for up/down commands looking like this:

(filepath:linenum)

Ie, there was no "<-", "->", "++" or "--" prefix. So the rxmakepos regular expression needs to accomodate all possible permutations of prefices and also without a prefix.

Ok, I've uploaded a new patch that has the fix for up/down commands, "DDD_remake_repairs_attempt5.patch".

Finally, this DDD-remake pair is starting to behave in a more pleasant manner! :)

(file #31662)

Gurce Isikyildiz <gurce>
Mon 30 Jun 2014 12:14:05 AM UTC, comment #9:

Ok, I've tweaked the reg-exp to work for prompts like this:

remake<<<<<...0>>>>>...

Actually, it needed more than a reg-exp tweak, as there was an extra test within GDBAgent::ends_with_prompt() that was looking for a '>' as the 2nd-last character (which was failing).

No worries, fixed that now.

I also believe I'm listening to the "<-". "->", "++" and "--" prefices correctly now too.

Ok, I will upload "DDD_remake_repairs_attempt4.patch" to resolve this.

Next time, will focus on the up/down command issues with the source-pane...

(file #31640)

Gurce Isikyildiz <gurce>
Sun 29 Jun 2014 11:11:03 PM UTC, comment #8:

Yep, follow what your saying. In my own head, I was using the 'nested' term in my own artistic way to equate to recursion ;) (ie, many Makefiles nested within a sea of sub-folders).

So I understand the "<" and ">" pairs are as you explained, but I still didn't comprehend the purpose of the "<..." and ">..." pairs. Not sure what the "..." ellipsis dots are trying to convey.

Anyway, I've tweaked the reg-exp to suit this.

I get the feeling I also need the reg-exp to test for all the "<-", "->", "++", "--" prefices to the "file:position" information.

I'm trying to read the remake docs to hone in on the meaning of each prefix:

"->" = We have not done pre-req check on this target
"<-" = We have done it (?)
"++" = About to execute recipe lines between "##>>>>>" and "##<<<<<"
"--" = (not sure)

Hmm, I also noticed that the "up" and "down" commands aren't changing the pointer position in the source.

I'll try iron out these aspects when I next get a chance...

Gurce Isikyildiz <gurce>
Sun 29 Jun 2014 10:00:16 AM UTC, comment #7:

Each pair of <> indicates an invocation of remake. This is called "recusive make". See https://www.gnu.org/software/make/manual/html_node/Recursion.html

This is in contrast to one target depending on another target inside a single invocation. For example

a: b

b:
# You can get here when running "make a". This is not recursion.

Rocky Bernstein <rocky>
Project Member
Sun 29 Jun 2014 09:19:34 AM UTC, comment #6:

Argh, bumped into another issue. It's all happily working for quite a few nested calls to remake, but after a certain depth of nested calls, it no longer updates the source-window.

I suspect it has something to do with the way the remake prompt appears on each nested call:

remake<number>
remake<<number>>
remake<<<...number>>>

I can't say I'm familiar with the distinctions between all these prompt-formats yet, but I think each extra '<' and '>' pair is another nested call to remake.

It's this 3rd style though with the '...' prefixing the number that seems to be tripping up the regular expressions that try to catch the command-prompt in the received output.

I'll try chase this up soon and update my patch...

Gurce Isikyildiz <gurce>
Sun 29 Jun 2014 03:56:38 AM UTC, comment #5:

Okidoke, I've got a fix for this issue too. It turned out to be due to a test inside SourceView::file_matches() to see if the filename has changed. It was comparing "pathA/Makefile" to "pathB/Makefile" as simply "Makefile" vs "Makefile", and saying the files were equal (so no need to update the source window).

Ok, I've now forced it to do the comparison with the full pathname instead, and the source-window properly jumps from Makefile-to-Makefile, nice :)

I'll upload a new patch now "DDD_remake_repairs_attempt3.patch".

I've also added a fix to an issue mentioned in these posts:

http://savannah.gnu.org/bugs/?33960
http://savannah.gnu.org/bugs/?30862

Their suggestion to a build-issue was to " #include <cstdio>" in "strclass.C". That worked for me, so I added it into the patch too...

Gurce Isikyildiz <gurce>
Fri 27 Jun 2014 12:11:59 AM UTC, comment #4:

Argh, I've noticed a shortcoming of my current fix. If one makefile calls another makefile, it's not updating the source window with the source of the next makefile (ie, it keeps showing the source of the parent makefile).

So I'll just leave this note as a reminder to myself, whenever I get a chance to look into it further (or in case anybody else wants to dig further too).

Gurce Isikyildiz <gurce>
Mon 31 Mar 2014 10:13:27 AM UTC, comment #3:

Ok, did some more digging and have finally got the source displaying in the source-pane, the command-tool window appears, and the green-pointer seems to be moving around from place-to-place when you do n/next.

I haven't tested thoroughly, so there may be other quirks I didn't notice.

Some of the gotchyas repaired on this occasion seemed to be related to the regular-expression used to figure out what line-number the execution is at.

Ddd has code in PosBuffer:make_filter() that attempts to read this info from remake output, eg, a line in the form (FILE:LINE), like:

"-> (/home/sgp1000/projs/ddd-git/Makefile:422)"

The catch was that the regex wasn't expecting the "->" arrow prefix at the front. It also assumed there would be a ':' colon at the end. Perhaps it was an older style of output.

Ok, I'll upload a new patch, "DDD_remake_repairs_attempt2.patch", that covers my last post's point and this stuff.

And some further insights into my last foray and my observation about it not using the decommissioned GNU RX library.

It seems that the new ddd version is more than happy to work without this rx library. It instead grabs the reg-exps from the "rxscan.L" file, so I applied the "mdb<...>" to "remake<...>" change in there, instead of my workaround in the previous attempt.

(file #31090)

Gurce Isikyildiz <gurce>
Sun 30 Mar 2014 01:31:55 PM UTC, comment #2:

One way to try to find where to look to change this migh tbe to look at the changes that were made to get this in there in the first place. Looking at svn log it seems that this was done in the pydb branch starting at r6763:

> r6763 | rockyb | 2005-11-19 22:38:12 -0500 (Sat, 19 Nov 2005) | 2 lines
>
> Add support for the new GNU Make debugger makedb!


Unfortunately there is not document on how to add a new debugger nor is there really a centralized place to to make changes. Too many of the changes are in files scattered hither and yon.

Rocky Bernstein <rocky>
Project Member
Sun 30 Mar 2014 11:43:33 AM UTC, comment #1:

Well, I kinda got the same message under different circumstances. Perhaps related, perhaps not. But just in-case, I'll share.

My scenario. I'm on an OpenSUSE 12.3 (32-bit) pc running the latest ddd 3.3.12 and remake (make3.82+dbg0.9).

More details on the steps to replicate my issue here:

https://github.com/rocky/remake/issues/6

At the end of it, after typing "exit", I still wind up with that "GDB could not be started" error message.

One additional observation; prior to me typing exit, not only is the mouse pointer an hour-glass, but in addition, I also noticed that the status bar has a message "Opening session 'abc123etc...'" stuck in it. It doesn't ever go away...

I've been doing a lot of debugging of the ddd code to try figure this out, as Rocky mentioned that nobody seems to be maintaining this ddd code anymore, it hasn't been touched since 2009.

I've got a few leads, but not a full solution yet.

I've overcome one issue. Inside "GDBAgent.C" - ends_with_prompt(), there is code to handle parsing of output from remake/gdb/bashdb/etc. There is a test to detect the prompt-message in these, eg "(gdb)" for gdb, "bashdb<...>" for bashdb, and "mdb<...>" for remake.

But the latest version of remake uses a "remake<...>"-style prompt.

So I tried tweaking the code to look for "remake<" instead, but still had problems.

There is some extra string-matching tests done that use the GNU RX library (via a RUNTIME_REGEX define).

I noticed inside "config.h" that RUNTIME_REGEX has been set to zero, with an interesting comment preceding it saying that it used to be turned on in ddd version 2.1 and older, but was turned off in newer versions (to save on memory and speed).

I thought I might be able to manually turn this setting on, as I saw this old post of somebody doing similar.

http://lists.gnu.org/archive/html/bug-ddd/2004-05/msg00030.html

But reading here, the GNU RX library has been decommissioned.

https://www.gnu.org/software/rx/rx.html

So as an alternate workaround, I tried commenting out the use of the rx-library in the search for the "remake<...>" prompt. There is a 'possible-match' method used prior to using the rx-method, and I just contented myself with a 'possible-match' and returned true.

I tried running ddd after this tweak. It seemed to get one thing fixed, the status bar no longer has the "Opening session 'abc123etc...'" message in it, but I see a "Welcome to DDD 3.3.12 "Dale Head" (i686-pc-linux-gnu)" message instead. That sounds better...

I also see a "tip of the day" popup window, which I didn't see before.

Other elements are still missing though:

1) the 'command tools' box was missing, but I noticed I could toggle this on from the menus with "View >> Command Tool..." instead.

2) there still isn't any source displaying in the top-pane.

Hmm, ok then. I'll try debug the source-pane issue in future and hope I get to the bottom of it...

Another approach that Rocky suggested was to use an older version of remake from the time this ddd version was released. I haven't given that a try yet. (I was a bit wary of this, as I recall having problems with an older version of remake in opensuse and had to upgrade to a newer version, but I may give it a try later out of desperation)

I'll also upload my semi-finished patch, just in-case I give up on this, and somebody else wants to push the study into this issue further.

Gurce Isikyildiz <gurce>
Thu 29 Apr 2010 07:00:47 PM UTC, original submission:

I tried to use DDD with remake but got this error:

"GDB could not be started"

The command line I was using is:

ddd --remake

I am wondering what the problem is.

gnu user <gnuregisterme>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rocky (Posted a comment)
  • -unavailable- added by gurce (Posted a comment)
  • -unavailable- added by gnuregisterme (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 02 Jul 2014 12:23:23 PM UTCgurceAttached File-=>Added DDD_remake_repairs_attempt5.patch, #31662
    Mon 30 Jun 2014 12:14:05 AM UTCgurceAttached File-=>Added DDD_remake_repairs_attempt4.patch, #31640
    Sun 29 Jun 2014 04:06:22 AM UTCgurceAttached File-=>Added DDD_remake_repairs_attempt3.patch, #31630
    Mon 31 Mar 2014 10:13:27 AM UTCgurceAttached File-=>Added DDD_remake_repairs_attempt2.patch, #31090
    Sun 30 Mar 2014 11:50:59 AM UTCgurceAttached File-=>Added GDBAgent_remake_prompt_workaround.patch, #31076

    Back to the top


    Powered by Savane 3.1-cleanup