Subject:
Re: [gnupic] gplink and .lst files
From:
Craig Franklin ####@####.####
Date:
30 Mar 2006 03:29:55 +0100
Message-Id: <442B440D.1020101@users.sourceforge.net>
George M. Gallant, Jr. wrote:
>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
>
>
>
Ahh, there is the problem. Why are you using the same name for both?
That must be confusing.
The list file isn't the only problem. Both tools can also create and
delete cod, hex, and coff files. When errors occur both tools delete
most of their output files.
Even if we change gputils like you have requested, this isn't a very
good practice.
>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,
>
Good point. I don't remember what they do.
> but
>
> ARC
> DEC
> Borland
> SUN
> Microsoft
> GNU
>
>supply options to enable/disable features that only do what the writer
>requested.
>
>
>
That is not exactly what is happening here. You have explicitly told
the tool to do something, -l. The disagreement is over what -l should do.
I am not completely against changing it. I would like to have a good
justification. I don't view using the same name for a component and the
linker output as a good practice. So it is tough to change it on that
basis.
>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.
>
>
>
I will think about this and get back to you.
>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: ####@####.####
>>
>>
>>
>
>
>
