[Info-vax] OT: lightweight 90s viewer for Level 2 Postscript. Plus compiler-related obscureness.

[John Wallace]

On Aug 23, 12:56 pm, Simon Clubley <clubley at remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2012-08-23, John Wallace <johnwalla... at gmail.com> wrote:
>
>
>
> > The tests for compiler A and compiler B use the same source (and
> > indeed the same build process, including the same makefiles, linker
> > config files, etc), but the results are different. So look at the
> > generated code and data and any other relevant files and work out
> > what's different and what differences make one set fail. Fortunately
> > it's a small embedded environment, only a tiny part of which is
> > relevant.
>
> What about the startup code ?
>
> > Both of these interim file sets have the characteristic that addresses
> > aren't resolved at that stage, which depending on needs can be A Good
> > Thing or A Bad Thing. In this case I concluded that comparing all
> > those unresolved addresses all showing as zero was A Bad Thing.
> > Ultimately most of the comparison was performed on disassembly of
> > relevant sections of the fully linked executable, with fully resolved
> > addresses.
>
> My personal preference in this case is to run objdump on the final
> executable, pull the listing file into emacs and then look at the bit
> of code I have some suspicions about. I never bother with the
> .o files or the .s output from the compiler.
>
>
>
> > After days of analysis not just of disassembled source but of gdb
> > trace logs, the code turns out to be functionally identical anyway,
> > according to current analysis. The failing is in the data generated by
> > the compiler(s) as part of the test input.
>
> > An array of pointers to variables is involved as input in several of
> > the failing tests. In the 'fully' investigated test, in the one which
> > passes, the array of pointers is allocated in ROM and all is well. In
> > the one which fails, the array of pointers is allocated in BSS and
> > does not appear to be initialised (this bit needs analysing further).
>
> Given the pointers in the latter example are in .bss and not .data, I am
> assuming you are setting up the array at runtime instead of build time.
>
> In the startup code for this board, does .bss get zeroed before control
> is passed to your code, or does your code have to call some startup
> routine which causes .bss to get zeroed at that point ?
>
> I'm wondering if .bss is getting zeroed after the array has been setup
> instead of before the array setup code.
>
> > So when the array is passed to the routine that uses it, there's
> > nothing there for it to use (in the failing case). There is no accvio/
> > segfault, but obviously the result isn't what is expected either.
>
> > Sorry, no actual code snippets, but you can hopefully work it out.
> > Just think of an array of "char *" and you're not far wrong.
>
> Simon.
>
> --
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Some good questions and suggestions there, but I'll go straight to the
answer as it looked earlier today.

Who speaks Ada round here? The following example illustrates the
principle rather than the exact syntax (which, being Ada, is
inevitably much more complex than I can remember, though I can happily
read Ada and have been doing so for far too long).

What's the difference between an Ada array whose elements are
initialised using something like:
array_instance : [const?] array_type := (scalar_a'address,
scalar_b'address ...);
and an array initialised using the notation
array_instance : [const?] array_type := ( 1 => scalar_a'address, 2 =>
scalar_b'address);

The correct answer, apparently, is that they are intended to be
equivalent, at least in the obvious case where every element in an
array with an integer index is initialised (or something like that).

However, two of us independently spotted at the same time today that
the two notations when fed into the older compiler generate different
initialisers. One notation correctly generates initialisers which at
run time end up in the right place in ROM (if const) or RAM (if not
const). The other notation just allocates space in RAM (in bss) with
nothing to initialise it (not even something in ROM to copy to RAM to
set it up). The one with " => " is the wrong'un in this picture.

The newer compiler handles both variants successfully anyway.

So, it appears to be workable around for now even with the older
compiler.

Many years ago some customers I worked with would have suggested "feed
it to DEC Ada and see what happens, that'll tell you what's right. Or
look it up in the LRM". *They'd* have suggested it, not me ('cos I
wasn't, and am not, an Ada expert). Lack of DEC support for Ada 9x
means that idea often isn't an option these days.

Deeep joy.