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

[Simon Clubley]

On 2012-08-23, John Wallace <johnwallace4 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