[Nasm-bugs] [Bug 3392533] Considerations for segment support in ELF

noreply-nasm at gorcunov.org noreply-nasm at gorcunov.org
Wed Aug 14 00:32:49 PDT 2019


https://bugzilla.nasm.us/show_bug.cgi?id=3392533

--- Comment #92 from TK Chia <u1049321969 at caramail.com> ---
Hello hpa,

> > 1) Should the calculation for R_386_SEG16 be A + ((S + B) >> 4) rather than
> > A + (S >> 4)?
> No. R_386_SEG16 is used for object files (.o); B is undefined at this point.

But my understanding is that R_386_SEG16 is supposed to result in an MZ (or
R_386_SEGRELATIVE) relocation, which can only be resolved at runtime anyway. 
So I still suspect it should be A + ((S + B) >> 4).

> The st_size member of that symbol could then be used to indicate the size of
> the segment, although I have to admit I don't know offhand to make the linker
> do that

One problem is that there are generally lots of such auxiliary symbols for the
same segment (`environ!', `errno!', etc.), and I am not sure if there is a way
to simply equate one undefined symbol with another (e.g. declare that `errno!'
= `.data!', or `x!' = `.fardata.bar.c.44370$').

Another complication is that there is no obvious way to express "expand-down"
segments with this mechanism.  These are possibly useful --- I am currently
experimenting with these in my DPMI support code in newlib-ia16 (ia16-elf-gcc
-mdpmiable), to provide some measure of null dereference checking.

* * *

On a ... related note, I am currently re-running my regression tests on my
updated gcc-ia16 toolchain, and the new linker is currently crashing on the LTO
test cases.  I am not sure what is causing them, though it _might_ be that
there is some instability in the mainline Binutils head:

...
Running /home/user/.local/build-ia16/gcc-ia16/gcc/testsuite/gcc.dg/lto/lto.exp
...
FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link,
-flto -r -nostdlib
FAIL: gcc.dg/lto/20081120-2 c_lto_20081120-2_0.o-c_lto_20081120-2_1.o link,
-flto -flto-partition=1to1 -r -nostdlib
FAIL: gcc.dg/lto/20081204-1 c_lto_20081204-1_0.o-c_lto_20081204-1_1.o link,
-flto -flto-partition=1to1 -fPIC -r -nostdlib
FAIL: gcc.dg/lto/20081212-1 c_lto_20081212-1_0.o-c_lto_20081212-1_0.o link, -r
-nostdlib
ERROR:
/home/user/.local/build-ia16/gcc-ia16/gcc/testsuite/gcc.dg/lto/20081212-1_0.c:
error executing dg-final: child process exited abnormally
FAIL: gcc.dg/lto/20081224 c_lto_20081224_0.o-c_lto_20081224_1.o link, -flto
-flto-partition=1to1 -r -nostdlib -fPIC
FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -flto
-flto-partition=1to1 -fPIC
FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o link, -O0
-flto -flto-partition=1to1
FAIL: gcc.dg/lto/20090126-2 c_lto_20090126-2_0.o-c_lto_20090126-2_0.o link,
-fPIC -O2 -flto -flto-partition=1to1
...

This is not a show-stopper, but I hope to be able to track down the cause of
these crashes some time soon.

Thank you!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.


More information about the Nasm-bugs mailing list