gnupic: Re: [gnupic] gplink and .lst files
Subject:
Re: [gnupic] gplink and .lst files
From:
"George M. Gallant, Jr." ####@####.####
Date:
28 Mar 2006 14:02:43 +0100
Message-Id: <1143550954.12961.62.camel@scuba.home.net>
The problem arises when a one of the component asm files has the same
base
name as the linker output file. For example this is my typical:
gpasm graig,asm -> craig.o & craig.lst
gpasm i2c.asm -> i2c.o & i2c.lst
gplink qcraig.o + i2c.o -> craig.hex & craig.map
Identical sequences for 68k, ARM projects using the GNU tools.
I have not used the Microchip tool set since gputils started supporting
relocatable object files so I can not comment on their behavior, but
ARC
DEC
Borland
SUN
Microsoft
GNU
supply options to enable/disable features that only do what the writer
requested.
Since gputils has become quite stable :), the time required for me to
hack
gputils is not very long and perhaps I could post the mods on a private
web page.
George
On Tue, 2006-03-28 at 00:11 -0600, Craig Franklin wrote:
> George M. Gallant, Jr. wrote:
>
> >Craig,
> >
> >The difference is gplink has a -l option which is
> >is supposed to "Disable list file output." Thanks
> >for pointing out a weakness in gpasm.
> >
> >
> >
> I forgot how much fun this is. I am glad to be back :)
>
> So you have a project whose target is my_build.hex. You want to add a
> -l to gplink to prevent it from generating a list file and keep another
> file not generated by gplink but named my_build.lst in the same
> project. I will ask again, why? Are you using some other method to
> generate a list file?
>
> A few years back I was working on fixing a gputils bug. Can't remember,
> but I think it was in the COD files. Those files are managed the same
> way the list files are. Problem was the COD file I was debugging didn't
> match the hex file because the COD file was being suppressed, but the
> output file wasn't being deleted. A very frustrating way to waste
> time. If it happens to me, I am sure others have experienced it.
>
> If you have a real good reason not to do it, I am listening. So far the
> only thing I am hearing is you don't like it.
>
> >George
> >
> >On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:
> >
> >
> >
> >>George M. Gallant, Jr. wrote:
> >>
> >>
> >>
> >>>Craig,
> >>>
> >>>I find 2 problems with the current scheme:
> >>>
> >>> 1. gpasm and gplink both produce xxx.lst files.
> >>>
> >>>
> >>>
> >>>
> >>They also both generate .hex and .cod files.
> >>
> >>
> >>
> >>> 2. gplink deletes the xxx.lst file even if it is not writing one
> >>>itself.
> >>>
> >>>
> >>>
> >>>
> >>gpasm deletes xxx.lst files even if it is not writing one too.
> >>
> >>Here is the problem with your scheme: I compile my project with the
> >>list file enabled. Then later suppress the list file output and keep
> >>building the project. The list file won't match any of the current
> >>outputs. This is confusing at a minimum.
> >>
> >>If you want to keep a file, whether it is a hex, cod, list,... rename it
> >>or move it. Why do you want to keep a list file that doesn't match any
> >>of the other outputs?
> >>
> >>
> >>
> >>>George
> >>>
> >>>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The current behavior is to prevent old stale list files from being
> >>>>confused with current hex files. All the gputils tools behave this way
> >>>>for all file types.
> >>>>
> >>>>Best thing to do is to rename your file. This will also help prevent
> >>>>gputils from over writing your special list file.
> >>>>
> >>>>George M. Gallant, Jr. wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>I typically use the -l option to gplink to inhibit the creation of the
> >>>>>composite .lst file.
> >>>>>A side effect is gplink deletes the existing .lst file. Moving the the
> >>>>>code at approx
> >>>>>lines 267-268 264 makes seems to correct this behavior.
> >>>>>
> >>>>>New code:
> >>>>>
> >>>>>void write_lst(void) {
> >>>>>gp_symbol_type *symbol = state.object->symbols;
> >>>>>gp_aux_type *aux;
> >>>>>gp_boolean first_time = true;
> >>>>>
> >>>>>if(!state.lst.enabled)
> >>>>> return;
> >>>>>
> >>>>>lst_init();
> >>>>>
> >>>>>list_enabled = true;
> >>>>>
> >>>>>Thanks,
> >>>>> George
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: ####@####.####
> >>>>For additional commands, e-mail: ####@####.####
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: ####@####.####
> >>For additional commands, e-mail: ####@####.####
> >>
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
