#68 BUGFIX: Memory alloc bug in link/z80/lklibr.c

[Philip Pemberton]

There's a nasty bug on line 289 of
sdcc/link/z80/lklibr.c -- a memory buffer is allocated
for a string, but that buffer is one byte too small and
the trailing null ends up clobbering other memory. This
causes a segfault to occur later in the code.

The fix adds 1 to the buffer length to account for the
trailing null.

This bug was first detected on version 2.6.0, but I
think it might also exist in earlier versions.

[Philip Pemberton]

link-z80 memalloc bugfix

[Borut Ražem]

Logged In: YES
user_id=568035

Bug is already fixed in as/mcs51/lklibr.c and
as/hc08/lklibr.c. Probably the link/z80/lklibr.c should be
synchronized with (one of) them.

Borut

[Frieder Ferlemann]

Logged In: YES
user_id=589052

> Probably the link/z80/lklibr.c should be synchronized with
(one of) them.

should synchronization be done by hand, by an #include
"../mcs51/lklibr.c" or would a symbolic link be portable enough?

A similar synchronization problem also exists for library
files. Could files like "device/lib/_strlen.c" and
"device/lib/pic16/libc/string/strlen.c" be unified?

[Maarten Brock]

Logged In: YES
user_id=888171

Synchronization should be done either by hand or by
factoring out the file to a common place. Having the z80
linker use files in the mcs51 tree seems incorrect to me.
I'll have a look at it.

The pic library sources were branched from the normal tree
on purpose I guess. I don't know why.

[Philip Pemberton]

Logged In: YES
user_id=386672

I agree - have a common codebase for the assemblers, then
have separate subdirectories for the target-specific stuff.
I'd do something like this:

asm/src/ - common code
asm/pic14/src/ - PIC14 assembler code
asm/mcs51/src/ - 8051 assembler code
asm/z80/src/ - Z80 and GBZ80 assembler code
(and so forth)

[Borut Ražem]

Logged In: YES
user_id=568035

...and don't forget the hc08 linker in as/hc08!

I don't understand why the linker code was branched. Why
should the linker be CPU dependent? GCC has a single linker
which can link the object files for much more CPUs,
different languages, object file formats, ...

I understand that there are some specifics in the debug file
formats, object file extensions, ..., but they can be
probably driven by command line options.

I think it would be optimal to merge all linker code to the
link/ directory and remove it from as/. But this is probably
not a trivial think to do and the risk is high :-(

Borut

[Frieder Ferlemann]

Logged In: YES
user_id=589052

> but they can be probably driven by command line options.

This could also be achieved (with no command line changes)
by parsing the filename with which the linker was called.

See Feature Request 1204438 "make SDCC a "multi-call" binary"
http://sourceforge.net/tracker/index.php?func=detail&aid=1204438&group_id=599&atid=350599
and the patch appended there.

[Borut Ražem]

Logged In: YES
user_id=568035

I thing that the discussin here has gone too far away from
the original problem.

Maarten, I saw that you already assigned this bug to
yourself: I propose to fix only the bug as proposed by
Philip and open a new feature request for linker
synchonization / merge / unification.

Borut

[Maarten Brock]

Logged In: YES
user_id=888171

Bug fixed.
Linkers moved to as/link and subdirectories.
Some common files factored out to as/link itself.

SDCC 2.6.1 #4442.