Re: Removing ARCNET stuffs

[Anders Magnusson <ragge%ludd.ltu.se@localhost>]

Andrew Cagney skrev den 2015-06-01 22:50:
> Like I mentioned in another reply, I'm being a little fast and loose.
>
> The file "cc/ccom/scan.l" from
> http://pcc.ludd.ltu.se/fisheye/browse/pcc/pcc/cc/ccom/scan.l?r=1.127
> which I'm assuming is the C parser is doing this:
>
> #define STABS_LINE(x) if (gflag && cftnsp) stabs_line(x)
> ...
> "\n"                    { ++lineno; STABS_LINE(lineno); }
>
> which, I believe, is executing this:
>
>          cprint(1, "\t.stabn %d,0,%d," STABLBL "\n" STABLBL ":\n",
>              N_SLINE, line, stablbl, stablbl);
>
> and this will will insert the stab into the assembler stream
> (send_passt).  However, and here's the key thing, as best I can tell,
> the stab isn't tied to an instruction, just a position in the
> instruction stream.
It is tied to a statement (which is the only thing known at that time) in
the statement stream.
> If an optimizer so much as sneezes, re-ordering instructions for
> instance, the information is wrong.
Not necessarily, since the optimizer is quite aware about the existance
of debug info,  and for stabs this is not a problem since it is 
statement-based
and will always put the line label at the correct place regarding 
statements.
If instructions between statements are interleaved we will always loose.
> When the back-end goes to generate assembler, all it has, is a string.
Which is sufficient in this case.  Another better way to do it would be to
tie the debug info to the statement struct, but it has not been any reason
to do that for stabs (which works well enough for normal debugging).
> In the case of variables.  They are generated at the start of a block,
> so have no connection at all to the code.
>
> perhaps I'm wrong?
They can be declared anywhere in the code, but nevertheless it do not matter
where as long as they refer to the correct function.
Note that the backend do not care about language, for example the f77 
compiler
is included in the package.  I haven't moved over the pascal frontend 
yet though :-)

-- Ragge