Ronald G Minnich <[EMAIL PROTECTED]> writes: > On 26 Oct 2001, Eric W. Biederman wrote: > > > Except the virtual addresses of variables in the data > > section are wrong and the code won't run. > > Well, this one I have not tried. But a very similar fix on the alpha did > work. > > Oh, I see what you mean, sorry. > > OK, don't know what to do. > > > With ld 2.10.90 I don't have any problems ld --version. > > that same version, same bfd library, breaks on alpha. > > > It seriously looks like simply having new enough tools might be > > the solution. Every time I have tracked it that was the problem/difference. > > In catani's case the tools are NEWER, and they went from working to broken > :-(
Ouch! Unless they are a development version. Until something better comes along the only obvious solution is to do the kernel thing and only compile with known good tools. At least ld told us when it broke. > I'd rather get to the point that we can work with any version of ld, that > may be impossible however. Right. I'd hate to push it to hard. I might be able to resolve the physical versus virtual address stuff with the work I am doing to get the use cache as ram. It is working pretty well, but I still need to implement the segment trick. My attempt at using PIC code isn't useful because it doesn't generate position independant data that doesn't need fixups when it is relocated. So I need to fix the virtual address, or pointers will be a problem. So far we only have the physical versus virtual distinction on x86 because we relocate just our data segment. If we relocated all of the code, and just pretended to be at the right address initially we can resolve that. I'm not too worried about multiple sections causing problems as the implicit scripts that ld uses also have multiple sections so the problem appears to be mostly related to forcing addresses and virtual versus physical distinctions. Eric
