Yes, this indeed would be best. The appearance of the internal functions in
the .dll 's external symbol table is not intentional (no external access is
intended). What remains is for me to scratch my pointy little head and try
to figure out how to do this moving forward with our ANSI C models and
gcc-driven makefiles to eliminate this exposure w/o trashing the existing
model source structure and workflow.
Bob
On Wed, May 6, 2015 at 12:01 PM, Mike LaBonte <mike@xxxxxxxxxxx> wrote:
Wouldn't it be best to statically link the private functions? There is no
need for them to show up in the symbol table at all. That way the function
names are taken out of the equation, all calls are made by fixed jump
offsets.
Mike
On 5/6/2015 12:25 PM, David Banas wrote:
Hi all,
I bumped into this, previously, and was able to prevent it, by using
*namespaces*.
Of course, there’s no guarantee that your chosen namespace name is unique,
but if you choose something like: “<company>.<device>.<tx|rx>”, it’s a good
bet.
-db
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Bob Miller
*Sent:* Tuesday, May 05, 2015 3:41 PM
*To:* Mike Steinberger
*Cc:* IBIS-ATM
*Subject:* [ibis-macro] Re: Link Optimization BIRDs
Mike --
Thanks for the elaboration. For the record, I always compile/link the
entire AMI model with a single build script. I deserve all the pain I get
if I compile two different functions with the same name into two different
parts of the same .dll/.so!
My primary concern is at run time. I have been burned in the past by a
customer using an older Tx model with a newer Rx model, the Tx compiled
with an older, slightly different version of an identically-named library
function (with a new element in the header) in the Rx. Recompiling the Tx
with the newer Rx library (with the function calls in the Tx fixed)
eliminated the problem (core dump). I then added a ""Kilroy was here"
printf to the function and recompiled and re-imported the Rx and -- lo and
behold -- when the EDA tool called Tx AMI_Init the aforementioned sentence
(only compiled into the Rx model) appeared in STDOUT. For the record, I
believe this EDA vendor fixed this problem on their end.
This has been observed only on one platform (and only crashed in 64bit
windows as I recall). But it raises an interesting question: Can it still
happen? What if two different model suppliers happen to use the same
internal function name? I think only the EDA tool (where the Tx and Rx
.dll/.so may be meeting for the very first time) can prevent this problem
and the implementation of the BCI flow in the EDA tool must be done
properly to prevent it. Existing flow implementations may somehow have
serendipitously avoided it. It might mean unloading each library before
loading/invoking the other, even while retaining in memory the model
structures created by each library. Ick.
Bob
On Tue, May 5, 2015 at 3:17 PM, Mike Steinberger <msteinb@xxxxxxxxxx>
wrote:
Bob-
You've brought up a really important point that affects all of IBIS-AMI.
My background wasn't quite sufficient, so I ended up consulting with our
local expert on software technology. It turns out that _what_ happens
depends on _when_ the functions were brought together. There are two
possibilities: compile time and run time.
Compile Time: If a set of interdependent functions is compiled all at one
time into a DLL or shared object library, then when one function calls
another, the compiler supplies the relative address for the function being
called. The called function is available at compile time and the compiler
knows about it, so it links the functions together in a way that makes them
inseparable. At this time, function names have been replaced by relative
addresses and are no longer part of the picture.
!!!->This is what should _always_ happen with an IBIS-AMI model.
!!!->Word to the wise: _Always_ link the _entire_ model at compile time in
a single build script or makefile, resulting in a _single_ DLL or .so file
to be delivered to users.
Run Time: Since the functions had no chance to get properly introduced at
compile time, they have to depend on being introduced by name at run time.
The names go into a symbol table, and functions find each other by name
through that symbol table (online dating service?). If two functions have
the same name it will probably be only the function that happens to occur
first in the symbol table that will ever get executed. This could easily
produce unpredictable results that would be extremely hard to diagnose.
- There are utilities for both Linux and Windoze that will enable you to
examine the contents of a DLL or shared object file, including the
dependencies between functions. This is a tedious business however, and not
anything we would ever want to subject our users to.
Thanks for bringing up this point.
Mike S.
On 05/05/2015 01:51 PM, Bob Miller wrote:
Re:/ link optimization workflow:
One issue I am a bit concerned about is the possibility of Tx-Rx
executable incompatibilities if they are both loaded and share function
symbol lookup tables. If both the Tx and Rx executables have different
internal functions with the same name, one might call the other's function
inadvertently.
I have seen (and painfully diagnosed) this in a real EDA platform in the
past.
Bob
On 04/29/15 06:00, Walter Katz wrote:
Fangyi,
Are you listing applicable training modes for each of the nine Tx-Rx
combinations?
WMK> Exactly so. This is “Informative”, not sure that it is required in
the BIRD, maybe in a supporting or cookbook document.
If so, can we simplify the table to the following 3x3 format?
WMK> Yes. Much easier to read and understand your simplified table –
thank you for doing this.
Tx Init only
Tx GetWave only
Tx Dual
Rx Init only
Init Training
None
Init Training
Rx GetWave only
Init Training (at input to Rx)
GetWave Training
Dual Model Training
GetWave Training
Init Training (at input to Rx)
GetWave Training
Dual Model Training
Rx Dual
Init Training
GetWave Training
Dual Model Training
GetWave Training
Init Training
GetWave Training
Dual Model Training
Modes
Training Mode
Tx Init Only
Tx GetWave Only
Tx Dual Mode
Rx Init Only
Init Training
Yes
Disabled
Yes
Rx Init Only
GetWave Training
Disabled
Disabled
Disabled
Rx Init Only
Dual Mode Training
Disabled
Disabled
Disabled
Rx GetWave Only
Init Training
Yes (optimizes at input to Rx)
Disabled
Yes (optimizes at input to Rx)
Rx GetWave Only
GetWave Training
Yes
Yes
Yes
Rx GetWave Only
Dual Mode Training
Yes
Disabled
Yes
Rx Dual Mode
Init Training
Yes
Disabled
Yes
Rx Dual Mode
GetWave Training
Yes
Yes
Yes
Rx Dual Mode
Dual Mode Training
Yes
Disabled
Yes
Walter
*From:* fangyi_rao@xxxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxxx
<fangyi_rao@xxxxxxxxxxxx>]
*Sent:* Tuesday, April 28, 2015 5:52 PM
*To:* wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
*Subject:* RE: Link Optimization BIRDs
Walter,
I am trying to figure out the meaning of the table on page 5 of the first
(BCI) BIRD. Are you listing applicable training modes for each of the nine
Tx-Rx combinations? If so, can we simplify the table to the following 3x3
format?
Tx Init only
Tx GetWave only
Tx Dual
Rx Init only
Init Training
None
Init Training
Rx GetWave only
Init Training (at input to Rx)
GetWave Training
Dual Model Training
GetWave Training
Init Training (at input to Rx)
GetWave Training
Dual Model Training
Rx Dual
Init Training
GetWave Training
Dual Model Training
GetWave Training
Init Training
GetWave Training
Dual Model Training
Thanks,
Fangyi
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Walter Katz
*Sent:* Tuesday, April 21, 2015 3:20 PM
*To:* IBIS-ATM
*Subject:* [ibis-macro] Link Optimization BIRDs
All,
I am enclosing the two BIRDs that I discussed in today’s ATM meeting.
They are mostly in BIRD format, but there is a lot of explanatory stuff
that may be re-organized into a separate document, so there will be lots of
editorial work to be done.
The BIRD the EDA tool needs to understand is LinkTraining_BIRD_Rev1.docx.
It describes the new reserved parameters and the flows that the EDA tool
needs to support. This BIRD is totally independent of the protocol, which
describes the content of the BCI branch that the Tx and Rx DLL’s put into
the AMI_parameters_out branch and the DLL’s put into the AMI_parameters_in
branch that get put into the subsequent Rx and Tx DLL calls.
The model writer needs to understand the content of these BCI branches for
any specific protocol (private, public, or IBIS approved). The IBIS
approval process is the standard BIRD process. I am also enclosing a BIRD
for a BCI protocol I have named “Basic” (Basic_Protocal_Pidgeon_Rev1.docx).
For amusement purposes I am calling Back Channel Protocols “Pigeons”, with
the mascot Back Cap’d Pigeon.
If a protocol name ends in .bci, then there should exist a .bci file that
both the Tx and Rx DLL can read (as requested by Ken at the IBIS summit),
but as I have written in LinkTraining_BIRD_Rev1.docx there is no
requirement that a protocol ends in .bci and therefor protocol can be
written without a .bci file.
I think that the “Basic” protocol BIRD that I am submitting, along with
the LinkTraining_BIRD_Rev1.docx describes a protocol that includes all of
the functionality requested for Rx models in BIRD 147. The key difference
is that there is no requirement for specifying specific stimulus patterns.
It has also been clear from talking to vendors of Tx AMI models that they
can easily write Tx DLL’s to support the full “Basic” protocol, while
vendors of Rx AMI models may choose to support only subsets of the “Basic”
protocol.
Note that if a Tx models supports the “Basic” protocol, or any other IBIS
approved protocols, there is nothing that prevents and EDA tool from trying
to optimize the Tx directly.
Also note that I have not included any description of a Meta file that
would allow an EDA tool from optimizing a legacy Tx model. I will leave
that to others to propose such a file.
My observations from today’s meeting is that there was a request to create
a new AMI_Impulse function to handle statistical communications between the
Tx and Rx.
I will not be able to attend next Tuesday’s meeting, so e-mail comments in
the meantime will be very much appreciated.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
--------------------------------------------------------------------- IBIS
Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
<http://cp.mcafee.com/d/5fHCMUg6zqb3dTD7T3hOOrKrhKYOUYCqehRPqdTCn7CrEECQrLcKf9CzAsyrhKqerII9zDCjq13org5vJ9mVsT-QBrBPtAhP1EVovvW_ee6zAsyMPRXBQXCzBzAmnzhOOqemk-mKzp55l6X7axVZicHs3jq9JcTsTsS02Z3u00UISgOh2lclSQqGRgYYlcimMT8xaxtnrhGn8lrxrMkX7_fBite00CT76kNNIQJO8iEnlSQqCBQQg0LQzh05pgaCy0cbjAH8kSsGMd40O6wIeEroKrK2Na>
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
<http://cp.mcafee.com/d/FZsS71MArhopKYU-UqemjtPqdTCn7APhOeKrhKYOUYPt54SztVBNVcQszAjqdPhPtBxcsYOrg8r3q0HZFaTbC_SAHsKrIyeod7b3X_nVNMQszAm6uLsKDsQsIsyOYqemjhOODORQr8EGEToVkffGhBrwqrjdFCXCXCM0jIvY-l9QU03xYGjOh2l2WKSzkT8xaxtnrhGn8lrxrMkX7_fBite00CT76kNNIQJO8iEnlSQqCBQQg0LQzh05pgaCy0cbjAH8kSsGMd40O6wIeEroKr2MMOsRUh>
To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
